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