在許多專案中，都會涉及到資料許可權問題，所謂資料許可權是表示，在系統中即使角色相同，都有操作許可權，但業務操作時受風險、額度、銷售區域等業務屬性限制。
如銷售人員可以看到自己的銷售列表，而銷售經理可以看到其管轄範圍內的銷售人員的銷售列表，而高階銷售經理能看到其下轄的銷售經理的銷售列表，更進一步，只看金額超過
1000
萬的單子，小於
1000
萬的單子不看。如銷售人員是銷售產品的，但由於產品屬性的不同，如產品屬性中銷售地區在「蘇杭地區」，則北京地區的銷售人員則不能銷售。如產品屬性中風險屬性高，則銷售人員的級別也要求高，則低階別的銷售人員則不能銷售該產品；進一步來講，隨著時間或形勢的發展，該種產品的風險並沒有那麼大，低階別的銷售人員也可以銷售；或者該種產品低階別的銷售人員銷售該種產品的金額小於
100w
，而高階別的人員銷售
100w
等等。在設計之初就確定了資料許可權所處的位置，和操作許可權類似，操作許可權一般是放在
mvc的
controller
層，作為外掛程式來控制是否有操作許可權。資料許可權也可以這樣設計，但資料許可權更多地是和業務邏輯糾纏在一起，因此資料許可權可以作為外掛程式放在業務層（
model
），更優雅的設計是以模板模式在業務預設實現基類中，作為過濾。如下圖所示，
bizclass
其實代表業務層的複雜設計，在做分析設計的過程中，我的經驗是盡最大可能理解需求，並盡最大可能直白地把需求展現出來，而不是在設計之初先定義什麼設計模式，設計模式是在搞清楚需求並能夠給出較完整的設計思路後才考慮的。當然，在設計之初也要首先定義其所在軟體架構的位置。
從需求方面講，要達到根據操作人就能夠給出該操作人的資料許可權，包括查詢的詳細程度及資料操作規則等。從這兒我們就可以分析出來要獲取資料許可權，有兩個引數
userid,
bizname。
其實任何業務需求的設計的途徑都是類似的，都是「來料加工」，有原材料，有目標成品，然後把原材料加工成目標成品。當然在其中要考慮很多因素，物件導向的設計思想很重要，不要在設計之初就考慮要多少個表，表之間的關聯關係，什麼一對多，多對多，關聯表。首先要考慮需要業務上有那些需求，這些業務功能如何轉變成某些用例，這些用例是如何轉換成若干的業務類，這些類有那些屬性或方法來實現這些業務功能。而表僅僅是某些實體類的資料儲存，不能表現為業務邏輯。也很難體現設計者的思路。
系統設計中，往往會把操作許可權和資料許可權混為一談，使用角色許可權來控制，這其實就走入了誤區，因為操作許可權是解決能不能做的問題，資料許可權是解決做多大幅度問題。因為角色是沒有級別概念的，也就是說沒有上下級概念的。
因此在計了「崗位」的概念，崗位是分級別的，且上下級匯報關係的，在這兒還設計了區域（
region
）屬性，是基於某些需求需要，這樣設計是基於有些公司的管理是分為矩陣式管理，既有部門，也根據產品線分為事業群管理的。
如下圖所示，組織機構是分上下級的，組織機構中包含若干崗位，因工作職責定崗，使用者是屬於某個崗位的。這就和原來的設計中組織機構和人的關係中增加了崗位的中間層，也就是說，組織機構中只包含其業務中需要設定的崗位，這些崗位由人員來充實，換句話說，組織機構中不養閒人，呵呵！
崗位中乙個重要的概念是資源管理，為了簡化設計，某乙個崗位只是為處理單一的某個業務所設定的，其中
bizes
屬性表示該崗位所涉及的業務有若干的資源。
這組類的主要功能是完成原材料的準備及資料規則與崗位的對映，其中並沒有實體類參與，這些類背後需要資料的支撐，到這時再考慮資料儲存不遲。例如
bizdatruler
後面就需要實體類，可能是多個相關表的資料。 類
resource
中包含多個產品的資料許可權規則，在
productinfo
其中datarulers
表示（key=positiongradesvalue=bizruler
），在類
bizdataruler
屬性positiongrades 如：3
，4，5
，6，以逗號分隔，表示某個規則適用與某些級別的崗位，屬性
productrulers
的hashmap,
其中scope
中關於數字範圍用「
[()]
」表示，「
[」表示大於等於，「
(」表示大於，「）」表示小於，
"]"表示小於等於，如「
[300,550
）」表示大於等於
300，小於
500。如果是雜湊數，用「
{}」表示，如「
」表示只有屬性等於30，
40，50的才有資料許可權，如「
」在表示只在上海，蘇州，杭州有效。這就類似與格式化文字的處理方式，簡化了文字解析。
努力，在於我熱愛我的事業，與中國的軟體一起走向成熟，走向世界。
資料許可權設計初探
在許多專案中，都會涉及到資料許可權問題，所謂資料許可權是表示，在系統中即使角色相同，都有操作許可權，但業務操作時受風險 額度 銷售區域等業務屬性限制。如銷售人員可以看到自己的銷售列表，而銷售經理可以看到其管轄範圍內的銷售人員的銷售列表，而高階銷售經理能看到其下轄的銷售經理的銷售列表，更進一步，只看金...
資料許可權設計
資料許可權設計思考目前有關使用者許可權採用的比較多的都是基於rbac模型 目前有關使用者許可權採用的比較多的都是基於rbac模型，即通過對角色許可權的定義完成對使用者許可權的限制。有關功能許可權部分想必都比較清楚，就是將系統的功能模組劃分清楚，並賦予不同角色的訪問許可權，這樣在使用者訪問某個功能模組...
許可權設計（功能許可權與資料許可權）
許可權設計的最終目標就是定義每個使用者可以在系統中做哪些事情。當我們談到許可權的時候，一般可以分為 功能許可權 資料許可權和字段許可權 功能許可權 使用者具有哪些權利，比如特定單據的增 刪 改 查 審批 反審批等等 一般按照乙個人在組織內的工作內容來劃分 比如乙個單據往往有錄入人和審批人，錄入人具有...