權限系統是否要獨立於應用系統進行設計一直存在爭論,通用的權限成指數的提升了系統的複雜程度,同時執行也影響了系統的執行效率。可是一旦設計完成一個通用的權限系統,能夠用於多個項目,大大節省了成本。總結就是一句,爲一個項目設計一個權限控制系統是正確的,通用只是爲了方便後面項目的重用,節省後續項目的成本,固然前期須要投入了。設計
權限系統通常分爲功能權限、數據權限、字段權限三種,最簡單也是最容易設計成通用的就是功能權限。權限系統的設計說簡單也簡單,就是能知足當主體(用戶)要操做(訪問)某個資源(數據)時,去檢查下用戶是否登記過容許訪問這個數據了,最簡單地可能只須要一張表格就能完成。對象
功能權限blog
RBAC(Role-Based Access Control)一般應用於功能權限,數據權限和字段權限一般直接與User關聯。功能權限的常規設計思路就是用戶<->角色<->模塊(功能)兩兩關聯,當模塊特別多時每每就不給角色直接賦予可訪問哪些模塊,而是給幾個可訪問模塊的列表,這些列表中包含了一些模塊,一些系統稱之爲許可權列表(Permission List)。後面設計功能權限時將會加入許可權列表的概念,以適應複雜的項目。ip
數據權限資源
數據權限一般要依據規則設置,其核心就是如何設計合理的規則,規則主要包含與、或、非、異或、包含於等邏輯關係,然而關係謂詞左邊的對象和右邊的篩選條件根據目標系統的不一樣也不一樣,看下圖權限控制
若是不怕麻煩能夠用數據字典對「員工ID」、「ShipAddress」再進行管理,這樣這套數據權限管理就能夠通用了。我的以爲這樣作的意義不大,這些要判斷的對象在系統上線前基本上就定義好了,用一個XML配置這些項就能夠了。io
字段權限效率
字段權限是對功能權限另外一個維度的擴展,通常只管控到哪些字段能不能看,也有系統存在某些用戶對某個字段能改,某些不能夠,主要看管控的粒度。字段權限的控制採用反向受權(默認都容許,被記錄的是不容許訪問的)比較好。字段權限和功能權限的設計相似,只要用表記錄下來就好,系統有哪些字段能夠經過反射方式得到。擴展
後續將對三個權限分別進行設計,最終作成一個完整的權限系統。sed