大话设计，没有模式—通用权限设计与实现
当代码写多了，总有些是经验，但经验是什么呢？if…else用的次数比别人多？显然不是。有些超棒的设计可以谓之经验！ 功能权限 网络上流行的经典的权限设计是【主体】- 【领域】 - 【权限】( who、what、how问题原型 ) 的设计思想，其中： 【主体】可以是用户，可以是角色，也可以是一个部门 【领域】可以是一个模块，可以是一个页面，也可以是页面上的按钮 【权限】可以是“可见”，可以是“只读”，也可以是“可用”(如按钮可以点击) 为了简化程序开发，在 OpenAuth.Core 中去掉了权限的控制，简化为【主体】- 【领域】的模式，且【主体】限定为角色。 即只能给角色分配模块和按钮，不能直接分配给用户账号或部门。且一旦分配即表示该角色拥有操作该模块（按钮）的权限。 大道至简，标准的RBAC规范比这个还要简洁，所以它的生命力才最顽强。在此基础上，如果进行二次开发，进行更详细的功能权限控制，可以按照上面的思想进行改造。 数据权限 数据权限是在功能权限的基础上面进一步的扩展，比如可以查看订单属于【功能权限】的范围，但是可以查看哪些订单就是【数据权限】的工作了。 这里面的几个概念： 【资源】：数据权限的控制对象，业务系统中的各种资源。比如订单单据、销售单等。 【数据规则】：用于数据权限的条件规则 。 应用场景 销售单，可以由本人查看 销售单，测试角色能看到自己的订单 销售单