一般企業(yè)上的權(quán)限部分，都是區(qū)分為功能權(quán)限和數(shù)據(jù)權(quán)限。

一、功能權(quán)限

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

1、基于shiro框架

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

2、基于spring-security框架

這個(gè)顧名思義，spring全家桶的成員，與spring是無(wú)縫對(duì)接，但量級(jí)偏重，學(xué)習(xí)成本比shiro要大，而且常用功能方面相比shiro也沒(méi)有過(guò)多優(yōu)勢(shì)，所以現(xiàn)在應(yīng)該很少有用這個(gè)的，能用這個(gè)的都用shiro了。

3、其他方案

可以看下我之前寫(xiě)的一個(gè)方案，基于aop和注解做的，適合新手練習(xí)，只提供一個(gè)思路。
一個(gè)簡(jiǎn)單的權(quán)限系統(tǒng)模型

二、數(shù)據(jù)權(quán)限

數(shù)據(jù)權(quán)限就是控制用戶能看到哪些數(shù)據(jù)，不能看到哪些數(shù)據(jù)。比如部門(mén)負(fù)責(zé)人，默認(rèn)只能看見(jiàn)自己本部門(mén)下的數(shù)據(jù)，隔壁部門(mén)的一些數(shù)據(jù)一般是看不了的。
數(shù)據(jù)權(quán)限由于和業(yè)務(wù)緊密關(guān)聯(lián)，所以業(yè)內(nèi)一直也沒(méi)有一個(gè)統(tǒng)一的框架或者方案，一般都是硬編碼，我僅僅也是根據(jù)我遇到過(guò)的場(chǎng)景，提出一種稍微能規(guī)范化的思路，純個(gè)人想法，僅供參考。

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

模板模式，可以參考我之前寫(xiě)過(guò)的一篇介紹
[設(shè)計(jì)模式] ------ 模板模式

注：使用模板模式實(shí)現(xiàn)數(shù)據(jù)權(quán)限，個(gè)人感覺(jué)還不是最優(yōu)解，之所以使用模板，重在規(guī)范各個(gè)業(yè)務(wù)的邏輯規(guī)則順序。

三、總結(jié)

做權(quán)限，首先要分清功能權(quán)限和數(shù)據(jù)權(quán)限的界限，最好不要有交集，不要為了編碼方便，將二者揉起來(lái)，比如在數(shù)據(jù)權(quán)限的時(shí)候，很容易會(huì)想到要用功能權(quán)限里面的角色的部分，乍一看好像方便了不少，但對(duì)于日后維護(hù)，以及后面新員工的學(xué)習(xí)成本，都是很大的，因?yàn)橐坏┤嗥饋?lái)，相當(dāng)于就把功能權(quán)限和數(shù)據(jù)權(quán)限耦合了，我們知道，解耦是項(xiàng)目做大后特別麻煩的一件事，所以能在項(xiàng)目初期避免耦合的，就盡量避免。所以如果項(xiàng)目是團(tuán)隊(duì)多人協(xié)同開(kāi)發(fā)，大可將功能權(quán)限和數(shù)據(jù)權(quán)限交給兩個(gè)人同時(shí)做。各做各的，避免耦合。

總結(jié)

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

如果覺(jué)得生活随笔網(wǎng)站內(nèi)容還不錯(cuò)，歡迎將生活随笔推薦給好友。