一般企業上的權限部分，都是區分為功能權限和數據權限。

一、功能權限

功能權限，就是用戶登錄后，能看到哪些菜單，能看到哪些按鈕，能執行哪些操作的權限。
一般，功能權限，已經都有很成熟的業內方案和框架了。
比如有RBAC思想（Role-Based Access Control，基于角色的訪問控制）。
有三個概念：用戶，角色，資源。
用戶就是用戶，給用戶配置角色，給角色配置資源，這些菜單的訪問權限就是資源。
這樣一來，五張表就夠了。用戶表，角色表，資源表，用戶角色關系表，角色資源關系表。
一般業內方案有這幾種：

1、基于shiro框架

這個框架把登錄，驗證，功能權限都做了，是一個經典的，成熟的，輕量級的框架。適合與spring集成，但不僅僅限于spring框架。
shiro初衷只是為單體應用提供方便，但隨著熱度增加，現在不管是單體應用還是分布式集群，都可以，網上有大段大段的介紹，我這就不說這個了，可以自行去找。

2、基于spring-security框架

這個顧名思義，spring全家桶的成員，與spring是無縫對接，但量級偏重，學習成本比shiro要大，而且常用功能方面相比shiro也沒有過多優勢，所以現在應該很少有用這個的，能用這個的都用shiro了。

3、其他方案

可以看下我之前寫的一個方案，基于aop和注解做的，適合新手練習，只提供一個思路。
一個簡單的權限系統模型

二、數據權限

數據權限就是控制用戶能看到哪些數據，不能看到哪些數據。比如部門負責人，默認只能看見自己本部門下的數據，隔壁部門的一些數據一般是看不了的。
數據權限由于和業務緊密關聯，所以業內一直也沒有一個統一的框架或者方案，一般都是硬編碼，我僅僅也是根據我遇到過的場景，提出一種稍微能規范化的思路，純個人想法，僅供參考。

那就是使用設計模式中的模板模式，通過使用一個抽象類去定義好骨架，然后針對不同業務子類，將自己的實現補上就行。
一般骨架的步驟如下，就拿用戶只能看自己部門相關數據的這個權限舉例：
前提：一般業務數據，不會在數據上直接標注屬于哪個部門，因為部門架構一直會變，甚至會大變，所以一般都是在業務數據上掛的是責任人。
而且，一般數據權限還要滿足可配置，就好比得有一個配置，能指定讓A部門的人，也能看到B部門的數據，這種算特殊情況，我們得有個表去維護記錄。
1、拿到用戶的這個部門
2、拿到這個部門下的所有員工集合{a,b}
3、拿到特殊情況下，對應的所有員工集合{c,d,e}
4、將上兩個集合合并，作為默認情況下的員工集合A{a,b,c,d,e}
5、拿到本業務數據中所有的責任人集合B{a,b,c,x,y,z}，并與上面集合A合并，找出B集合中包含A集合的數據集合，我們叫最終集合C{a,b,c}
6、最后用員工集合C作為條件查出對應的業務數據。
以上第一步到第五步，都可以作為接口對子類下發，延遲實現，最終執行是第六步。
這樣就徹底規范了所有業務的數據權限的使用步驟，各個業務只管實現即可。以上步驟可以微調，看清道理即可。

模板模式，可以參考我之前寫過的一篇介紹
[設計模式] ------ 模板模式

注：使用模板模式實現數據權限，個人感覺還不是最優解，之所以使用模板，重在規范各個業務的邏輯規則順序。

三、總結

做權限，首先要分清功能權限和數據權限的界限，最好不要有交集，不要為了編碼方便，將二者揉起來，比如在數據權限的時候，很容易會想到要用功能權限里面的角色的部分，乍一看好像方便了不少，但對于日后維護，以及后面新員工的學習成本，都是很大的，因為一旦揉起來，相當于就把功能權限和數據權限耦合了，我們知道，解耦是項目做大后特別麻煩的一件事，所以能在項目初期避免耦合的，就盡量避免。所以如果項目是團隊多人協同開發，大可將功能權限和數據權限交給兩個人同時做。各做各的，避免耦合。

總結

以上是生活随笔為你收集整理的浅谈权限（功能权限数据权限）的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。