下面来说一说数据规则的权限。
关于数据规则
上一节说了一下数据规则想要实现的效果，综合来看其实就是实现一个动态的可编辑的数据过滤器。过滤器可以赋给角色，从而在用户访问数据时根据角色应用这些过滤器来过滤数据。
来看一下普通的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和数据库的一些性能。
- 数据规则目前可以实现单个实体的过滤。多个实体的连接过滤等通过表达式树也可以实现，只是数据结构会非常复杂，而且在组合表达式树和存储时会浪费更多的资源。
下一节谈一谈系统的登录认证授权的流程。