下面來說一說數據規則的權限。
關於數據規則
上一節說了一下數據規則想要實現的效果，綜合來看其實就是實現一個動態的可編輯的數據過濾器。過濾器可以賦給角色，從而在用戶訪問數據時根據角色應用這些過濾器來過濾數據。
來看一下普通的sql語句：
SELECT * FROM Persons
WHERE (FirstName='T' OR FirstName='W') AND LastName='C'
拆解一下where
- 有三個簡單條件：FirstName='T' ， FirstName='W'，LastName='C'
- 兩個組合條件：(FirstName='T' OR FirstName='W') ，(FirstName='T' OR FirstName='W') AND LastName='C'
所以說要想實現這樣一個簡單的查詢，需要定義下邊這些內容：
- 條件：可以拆解爲左側表達式，操作符，右側表達式。對應上邊的三個表達式。
- 組合條件：由條件組合而成，幷包含條件之間組合的操作符：OR，AND等。
- 組合條件組：記錄這個過濾器的數據。
所以數據庫設計是這樣的（都繼承於BaseEntity）：
其中RuleGroup代表上邊的【組合條件組】，Rule代表【組合條件】，RuleCondition代表【條件】。Entity記錄了你想要進行數據規則管理的實體的信息。Rule和RuleConditon組成了樹狀結構，然後樹結構的記錄方式並沒有像前邊元素和組織那樣採用閉包的方式，而是使用傳統的記錄父ID的方式。
在程序中這三個表並不是直接對應sql的轉化。程序中使用的ORM是EFCORE，沒有使用動態拼sql的方式去拼接過濾器，而是通過表的數據直接生成表達式樹然後轉lambda去過濾數據。並且使用EFCORE的一個好處是，EFCORE可以通過不同的數據庫提供程序來保證在不同數據庫上的運行，避免了因數據庫不同而導致的SQL的差異問題。關於具體實可以看代碼。目前的版本實現了兩個動態字段，登錄用戶名和用戶組織，以後有時間會添加更多字段。下邊截圖看下效果。
以上就是權限管理的數據庫定義了，感覺有以下幾個問題：
- 在程序中，組織和用戶綁定時，並不是通過AspNetUserClaims。因爲組織和用戶是一對一的關係，爲了加快效率在程序中直接將組織的ID定義到用戶表內。
- 目前使用AspNetUserClaims和AspNetRoleClaims記錄所有用戶和角色的權限。當這個系統變大時，權限內容非常多時，把AspNetUserClaims和AspNetRoleClaims分表就有必要了。需要針對比較多數據的權限內容，建立獨立的綁定表來加快訪問速度。
- 關於數據規則，RuleGroup起到的作用，只是在目前單實體過濾情況下，用來記錄實體信息和關聯角色使用。現在因爲有動態字段，所以只是在登錄時讀取數據庫生成過濾器並緩存。考慮以後把Expression持久化到RuleGroup中，然後在登陸時再讀取拼接，提高cpu和數據庫的一些性能。
- 數據規則目前可以實現單個實體的過濾。多個實體的連接過濾等通過表達式樹也可以實現，只是數據結構會非常複雜，而且在組合表達式樹和存儲時會浪費更多的資源。
下一節談一談系統的登錄認證授權的流程。