資料許可權設計初探

在許多專案中，都會涉及到資料許可權問題，所謂資料許可權是表示，在系統中即使角色相同，都有操作許可權，但業務操作時受風險、額度、銷售區域等業務屬性限制。

如銷售人員可以看到自己的銷售列表，而銷售經理可以看到其管轄範圍內的銷售人員的銷售列表，而高階銷售經理能看到其下轄的銷售經理的銷售列表，更進一步，只看金額超過1000萬的單子，小於1000萬的單子不看。如銷售人員是銷售產品的，但由於產品屬性的不同，如產品屬性中銷售地區在「蘇杭地區」，則北京地區的銷售人員則不能銷售。如產品屬性中風險屬性高，則銷售人員的級別也要求高，則低階別的銷售人員則不能銷售該產品；進一步來講，隨著時間或形勢的發展，該種產品的風險並沒有那麼大，低階別的銷售人員也可以銷售；或者該種產品低階別的銷售人員銷售該種產品的金額小於100w，而高階別的人員銷售100w等等。

在設計之初就確定了資料許可權所處的位置，和操作許可權類似，操作許可權一般是放在mvc的controller層，作為外掛程式來控制是否有操作許可權。資料許可權也可以這樣設計，但資料許可權更多地是和業務邏輯糾纏在一起，因此資料許可權可以作為外掛程式放在業務層（model），更優雅的設計是以模板模式在業務預設實現基類中，作為過濾。如下圖所示，bizclass其實代表業務層的複雜設計，在做分析設計的過程中，我的經驗是盡最大可能理解需求，並盡最大可能直白地把需求展現出來，而不是在設計之初先定義什麼設計模式，設計模式是在搞清楚需求並能夠給出較完整的設計思路後才考慮的。當然，在設計之初也要首先定義其所在軟體架構的位置。

從需求方面講，要達到根據操作人就能夠給出該操作人的資料許可權，包括查詢的詳細程度及資料操作規則等。從這兒我們就可以分析出來要獲取資料許可權，有兩個引數userid,

bizname。

其實任何業務需求的設計的途徑都是類似的，都是「來料加工」，有原材料，有目標成品，然後把原材料加工成目標成品。當然在其中要考慮很多因素，物件導向的設計思想很重要，不要在設計之初就考慮要多少個表，表之間的關聯關係，什麼一對多，多對多，關聯表。首先要考慮需要業務上有那些需求，這些業務功能如何轉變成某些用例，這些用例是如何轉換成若干的業務類，這些類有那些屬性或方法來實現這些業務功能。而表僅僅是某些實體類的資料儲存，不能表現為業務邏輯。也很難體現設計者的思路。

系統設計中，往往會把操作許可權和資料許可權混為一談，使用角色許可權來控制，這其實就走入了誤區，因為操作許可權是解決能不能做的問題，資料許可權是解決做多大幅度問題。因為角色是沒有級別概念的，也就是說沒有上下級概念的。

因此在計了「崗位」的概念，崗位是分級別的，且上下級匯報關係的，在這兒還設計了區域（region）屬性，是基於某些需求需要，這樣設計是基於有些公司的管理是分為矩陣式管理，既有部門，也根據產品線分為事業群管理的。

如下圖所示，組織機構是分上下級的，組織機構中包含若干崗位，因工作職責定崗，使用者是屬於某個崗位的。這就和原來的設計中組織機構和人的關係中增加了崗位的中間層，也就是說，組織機構中只包含其業務中需要設定的崗位，這些崗位由人員來充實，換句話說，組織機構中不養閒人，呵呵！

崗位中乙個重要的概念是資源管理，為了簡化設計，某乙個崗位只是為處理單一的某個業務所設定的，其中bizes屬性表示該崗位所涉及的業務有若干的資源。

這組類的主要功能是完成原材料的準備及資料規則與崗位的對映，其中並沒有實體類參與，這些類背後需要資料的支撐，到這時再考慮資料儲存不遲。例如bizdatruler後面就需要實體類，可能是多個相關表的資料。

類resource中包含多個產品的資料許可權規則，在productinfo其中datarulers表示（key=positiongrades value=bizruler），在類bizdataruler 屬性positiongrades 如：3，4，5，6，以逗號分隔，表示某個規則適用與某些級別的崗位，屬性productrulers的hashmap,其中scope中關於數字範圍用「[()]」表示，「[」表示大於等於，「(」表示大於，「）」表示小於，"]"表示小於等於，如「[300,550）」表示大於等於300，小於500。如果是雜湊數，用「{}」表示，如「」表示只有屬性等於30，40，50的才有資料許可權，如「」在表示只在上海，蘇州，杭州有效。這就類似與格式化文字的處理方式，簡化了文字解析。

附錄：資料許可權模組設計類圖：

資料許可權設計初探

資料許可權設計初探

資料許可權設計

許可權設計（功能許可權與資料許可權）

相關推薦