在各種企業(yè)級(jí)系統(tǒng)開發(fā)的過(guò)程中難以避免都會(huì)遇到權(quán)限處理的設(shè)計(jì)。好的權(quán)限系統(tǒng)不但能為系統(tǒng)提供安全的解決方案，同時(shí)還能節(jié)約開發(fā)時(shí)間，提高系統(tǒng)的可維護(hù)性。
權(quán)限需求分為兩類：
A、模塊權(quán)限
操作功能模塊的權(quán)限，或者訪問(wèn)菜單的權(quán)限。比如用戶U有沒有權(quán)利操作“發(fā)票界面”。
B、數(shù)據(jù)權(quán)限
數(shù)據(jù)權(quán)限是對(duì)訪問(wèn)數(shù)據(jù)范圍的控制。
比如有1000張發(fā)票用戶U有權(quán)利操作哪些發(fā)票的控制，是操作所有的發(fā)票還是自己創(chuàng)建的發(fā)票或者是自己部門的發(fā)票。
C、字段權(quán)限
在有些時(shí)候我們會(huì)對(duì)特殊字段設(shè)置權(quán)限，比如客戶服務(wù)部是不可以看到客戶合同額的。
D、操作權(quán)限
操作權(quán)限是用戶對(duì)數(shù)據(jù)操作方式的控制，是創(chuàng)建、修改、刪除或者其它特殊權(quán)限，如共享等。
操作權(quán)限一般是基于模塊權(quán)限的。比如對(duì)用戶U的發(fā)票模塊操作權(quán)限的控制。但是有時(shí)候也會(huì)出現(xiàn)特殊情況，比如數(shù)據(jù)錄入員可以創(chuàng)建所有的數(shù)據(jù)類型而不能瀏覽、修改、刪除數(shù)據(jù)。
要?jiǎng)?chuàng)建適合自己項(xiàng)目的權(quán)限控制框架，需要根據(jù)自己項(xiàng)目需求來(lái)決定，適合自己的才是最好的，片面追求靈活與功能強(qiáng)大未必能給用戶提供最佳體驗(yàn)。在決定使用什么權(quán)限框架的時(shí)候建議使用能滿足自己項(xiàng)目需求的最簡(jiǎn)單的解決方案。
按需求分的話一般會(huì)有幾種的等級(jí)出現(xiàn)。
1。固定角色
由系統(tǒng)提供固定的幾種角色，這樣的系統(tǒng)一般需求比較穩(wěn)定，變化較少。比如論壇，提供管理員、版主、會(huì)員、非會(huì)員幾種簡(jiǎn)單的角色進(jìn)行權(quán)限的控制，就足夠適應(yīng)需求。使用這種方式由于角色固定，我們就可以在代碼中采用硬編碼，所以控制角色權(quán)限也好、控制數(shù)據(jù)權(quán)限也好都會(huì)比較簡(jiǎn)單。這種控制方式簡(jiǎn)單有效，能在最短的時(shí)間內(nèi)提供很好的安全控制。編碼簡(jiǎn)化不僅僅會(huì)降低開發(fā)成本，同時(shí)也會(huì)降低維護(hù)成本，更重要的用戶操作也會(huì)簡(jiǎn)化，易用性明顯提高。
如果你的系統(tǒng)使用這種方式就可以解決問(wèn)題那么絕對(duì)不提倡使用其它的解決方案。很多同事都會(huì)說(shuō)這樣如果遇到需求變化不就會(huì)經(jīng)常的需要修改代碼嗎？需求是層出不窮的，為了未可知的需求去大動(dòng)干戈，在一些未必會(huì)發(fā)生的事情上浪費(fèi)你的寶貴時(shí)間我認(rèn)為是非常不值得的。能夠滿足一段時(shí)間內(nèi)的需求同樣可以稱為一個(gè)好的系統(tǒng)。
當(dāng)然，如果你能明確的知道在未來(lái)不長(zhǎng)的時(shí)間內(nèi)這種方式并不能滿足你的需求的話，可以考慮下面的方案。
2。動(dòng)態(tài)角色：
很多項(xiàng)目并不是幾種固定的角色就能滿足系統(tǒng)要求。由于企業(yè)經(jīng)營(yíng)方式的改變可能會(huì)設(shè)置更多的崗位，更多的崗位帶來(lái)更多的角色需求。這時(shí)候采用固定角色就非常的失策。
a、模塊權(quán)限：
創(chuàng)建動(dòng)態(tài)角色來(lái)控制模塊權(quán)限并不復(fù)雜。我們只需要幾個(gè)表“功能表”“角色功能表”“用戶角色表”就可以實(shí)現(xiàn)我們的系統(tǒng)。
b、數(shù)據(jù)權(quán)限
數(shù)據(jù)權(quán)限的控制，一般會(huì)與組織結(jié)構(gòu)相關(guān)。在微軟的CRM中數(shù)據(jù)權(quán)限被分為全局、部門、下屬機(jī)構(gòu)、擁有等幾種。
全局：所有數(shù)據(jù)
部門：當(dāng)前部門的數(shù)據(jù)，不包括下屬機(jī)構(gòu)。
下屬機(jī)構(gòu)：下屬機(jī)構(gòu)的數(shù)據(jù)，不包括本部門。
擁有：自己擁有的或者創(chuàng)建的。
具體范圍等級(jí)的劃分也需要根據(jù)自己項(xiàng)目需求的不同而具體對(duì)待。比如，全局、下屬人員、自己等。
c、字段權(quán)限
字段權(quán)限的控制屬于權(quán)限控制中最繁瑣的控制，因?yàn)樽侄螜?quán)限的控制往往會(huì)脫離權(quán)限控制的范疇影響界面布局。
字段權(quán)限一般是依托與模塊權(quán)限的，我們需要設(shè)置“模塊字段表”，與“角色模塊字段表”來(lái)存儲(chǔ)角色擁有的字段權(quán)限范圍。
d、操作權(quán)限
操作權(quán)限是對(duì)具體某種用戶操作權(quán)限的控制，操作權(quán)限的控制往往也依托于模塊權(quán)限，偶爾會(huì)有特例。
不基于模塊的操作權(quán)限相對(duì)簡(jiǎn)單，只需要對(duì)操作權(quán)限設(shè)置“角色操作表”做單獨(dú)處理即可。
基于模塊的操作權(quán)限的控制相對(duì)復(fù)雜，需要設(shè)置“模
塊操作表”來(lái)維護(hù)模塊擁有的操作類型，同時(shí)設(shè)置“角色模塊權(quán)限表”來(lái)控制角色擁有的模塊操作范圍。
（注：上面提到的各個(gè)表只是舉例，并非什么經(jīng)典設(shè)計(jì)。）
事情往往會(huì)比上面列出的各種情況更復(fù)雜，當(dāng)各種權(quán)限糾集在一起就變得更棘手。
例如在CRM中就會(huì)出現(xiàn)同時(shí)并存的情況，首先是基本的動(dòng)態(tài)角色權(quán)限，然后是基于角色的模塊權(quán)限，然后是基于模塊權(quán)限的操作權(quán)限，又有與模塊權(quán)限交錯(cuò)的數(shù)據(jù)權(quán)限，再加上讓人頭疼的字段權(quán)限。我們就陷入了一片苦海。
最后還是要提醒各位同行在開始您的設(shè)計(jì)之前一定要搞清楚自己的項(xiàng)目需求，只有依托于需求的設(shè)計(jì)才能是好的設(shè)計(jì)，更不會(huì)白白浪費(fèi)你的汗水。千萬(wàn)不要迷失在追求全能的理想境界之中。