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