話說大家對RBAC權限模型應該是耳熟能詳了。但真正用的好的並不多。並且原始的RBAC模型並不包括數據權限的管理，網上也差點兒沒有相關的文章可以參考。本人經過幾個項目的實戰，在其基礎上擴展出一套可行的、簡單的數據權限模型，希望可以幫助大家解決數據權限管理上的老大難問題。
至於什么是數據權限，請移步我的其它文章，這里不再敷述。
1、關於角色的繼承：
在上圖描寫敘述的模型中，並沒有實現角色的繼承。既然一個用戶能夠分配多個角色，那么角色是否能繼承還有什么必要呢？實現這個毫無必要的功能須要大大添加應用的復雜度，可謂是得不償失。
2、關於資源和功能：
大家能夠從圖中看到僅僅有一張表的一個字段用來描寫敘述資源或功能的授權。在大多數場景中，資源和功能實際上無法進行嚴格的區分。有所差別的僅僅是顆粒度的不同而已。一個業務組能夠算是一種顆粒度最粗的資源。一個頁面或窗口相對就精細一些了；到頁面內菜單、工具欄button，就更精細了。假設控制的顆粒度達到頁面元素或界面控件的程度，就是最細顆粒度的權限控制了。所以不管你叫資源還是功能、操作。都沒有差別。你要控制的就是那些東西，僅僅須要你描寫敘述出來，就能夠被控制。
3、關於數據權限：
數據權限的授權相對功能權限來說，是全然不同的兩種類型。怎樣為數據授權，這必須從數據權限的本質出發，從怎樣鑒別數據出發，僅僅有可以像鑒別資源一樣對數據加以鑒別，我們才干對數據進行正確的授權。
假設我們拋開數據值的不同（值的不同不是本質的不同）來分析數據，就會發如今一般場景中，數據的不同首先是業務類型的不同。譬如：訂單數據、結算數據、生產計划數據等等。
對於同一類型數據，還能夠以產生數據的對象：業務部門、業務人員加以區分。這也是常常遇到的需求：經理能夠看到所有的訂單，業務員僅僅能看自己的。
什么叫所有？什么叫自己的？前一個概念對於不同的業務部門，實際的內容往往並不相同。A經理的所有訂單指的是A部門的訂單；而B經理的所有訂單則是B部門的訂單。
至於所謂的“自己的”。就更加明顯是一個相對概念了。張三的和李四的一般來說是不存在交集的。但有時候。也有一些絕對性的需求。譬如要求C部門的張三要管A部門訂單的審核，相同C部門的王五則負責B部門。
這樣，數據權限的授權必需要從相對和絕對兩個維度進行定義，才干做到邏輯完備。所以模型中也通過兩張表來描寫敘述數據權限，在相對模式中，用Mode字段來描寫敘述不同的顆粒度，而在絕對模式中用戶能夠直接指定部門或用戶的ID。此外，用ModuleId字段來定義數據的類型，也就是產生業務的模塊。這個字段所包括的邏輯不僅是差別數據的業務類型，更重要的是為應用數據權限提供根據。
4、關於權限的應用：
本人在項目中，功能權限和數據權限都應用在數據訪問層。利用數據庫函數返回給應用程序被授權的資源或功能的ID集合。
應用程序依據ID集合通過反射載入資源或功能，達到用戶不能訪問非授權資源的目的。數據權限的應用方法也差點兒相同，將數據庫函數join到業務表上去，未授權的業務數據就會被過濾掉。通過join添加的Permission列，則描寫敘述了該行數據的讀寫權限為僅僅讀還是讀寫。