權限抽象

權限抽象

背景

小時光開發到如今，量級也算比較大了，回想這一年，作了不少搬磚的事情，比方說更改權限、添加廣告位、增長記錄類型等，每一次更改都倒騰一次。因此想可否將這些易變的事情抽象出來，對修改封閉，對擴展開放，客戶端儘可能能不發版實現需求。因而，就有了一系列的思考。這篇主要是關於如何將權限抽象出來，作到之後更改權限方面的需求，儘可能能作到客戶端不發版直接搞定，Server端不改代碼或者少改代碼搞定。

依賴倒轉原則(Dependency Inversion Principle, DIP)：抽象不該該依賴於細節，細節應當依賴於抽象。換言之，要針對接口編程，而不是針對實現編程。

能力/角色	建立者	管理員	親友	粉絲	......
看記錄	Y	Y	Y	Y
刪除記錄	Y	N	N	N
小家更名	Y	N	N	N
邀請成員	Y	Y	Y	N
刪除成員	Y	Y	N	N
......

• 橫向（角色）延伸
• 縱向（能力）延伸

客戶端如何不發版，server端如何可以不改或者少改代碼？

客戶端

A. 增長一種角色 / 已有角色已有能力改變 （橫向）

舉例： 增長一種叫同事的角色

將目前的「經過角色肯定權限」的方式，改成統一經過server端詢問是否擁有能力。基本不須要知道角色這個概念。

拿「刪除記錄」按鈕是否應該顯示舉例：

B. 增長一種能力 （縱向）

(1) 能力是已有的功能，可是一開始沒有加權限判斷

以「查看家庭成員列表」爲例，原來有這個功能，任何人均可以進入這個頁面，沒有考慮權限的問題。

點擊「小家列表」後，將走小家列表路由（5），底層捕捉到這個路由URL，因爲是須要判斷權限的路由，經過Server判斷權限，若是沒有權限，則返回上一頁或者顯示無權限頁面。（2，3）

(2) 能力是沒開發的功能（好比增長一個備註暱稱的功能）

藉助頁面元素抽象化，以及RN，經過頁面元素抽象能夠動態增長一個入口，而後經過將頁面的重要參數（4）傳給RN，完成操做後RN能夠調用本地頁面方法，好比刷新頁面（1）。

Server

設計到3張配置表的維護

1. 角色表

1. 能力表

1. 角色/能力配置表

代碼相似：

// 角色爲「同事」可否查看「公開記錄」
bool checkAccessWithRoleIDAndService:(4,「get_public_data」); // Y

不管「增長能力」仍是「增長角色」都是維護着三張表。具體流程以下（以「可否查看評論」爲例）：