组织结构与权限模型设计（二）

前言

上篇文章组织结构与权限模型设计（一）中，介绍了权限模型的第一种实现方案，即用户与角色关联、角色与权限关联，职位作为用户的一个标签显示，不涉及权限。这种方案存在一个问题，通常我们说的权限，其实是包含两个维度：操作功能和数据范围。比如学校班级的班长有检查同学作业、布置任务的权利，这是说他能操作的功能；另外，班长只对本班级的学生有布置任务的权利，这里是对数据范围的限制。

 

方案二

基于上面的分析，可以认为权限是由操作功能和数据范围两个维度组成的，角色定义用户的操作功能，职位定义数据范围。在一个企业里面，不同部门的部门经理虽然职位是一样的（都是部门经理），但是他们所能做的事是不一样的：开发部的经理管项目开发事项、财务部的经理管理财务收支，映射到系统中，就是说他们的操作功能不一样。

相对第一种方案，模型没有发生变化，唯一改变的是对权限和职位的定义不一样了。

对于职位：在方案一中，职位只是作为一个标签显示，不带任何的语义，但是在方案二中我们需要用职位去管数据范围。要知道程序并不知道部门经理能够管理部门成员，对它来说这只是两个不同的字符串而已。有人可能会提出，程序加个if..else判断不就得了，但是要知道企业里面职位是五花八门的，有的公司可能叫部门经理为主任。为了应对这种可变性，我们需要对职位增加一个语义，告诉程序哪个职位是管理者，哪个职位只是普通成员。我们暂且叫这个语义为power，它有两个选择：Manager或Member。将这个语义属性附加到职位上，Manager是具有管理权限的人员，它能够管理本领域内的事项（领域的概念在上一篇中已介绍过）。

 

对于权限：在方案一中，没有将权限细分为操作功能和数据范围两个维度，权限既管操作功能也管数据范围。在方案二中，权限只定义操作功能，数据范围由职位决定。

 

打个比方，对于查看工作日志这个功能。

 

按方案二实现的话，系统中会有一个权限项，叫查看工作日志（操作功能），至于查看谁的工作日志（数据范围），则依据成员的职位，如果他是部门经理，则能查看整个部门的工作日志，如果他是普通成员，则只能查看自己的工作日志。将权限项赋给一个角色，再将这个角色和职位赋给用户，用户就具备了相关的权限。

 

按方案一实现的话，系统需要两个单独的权限项，叫查看部门成员工作日志、查看自己的工作日志。这两个权限项既定义了操作功能（查看日志），又定义了数据范围（看谁的日志）。将权限项赋给一个角色，再将这个角色赋给用户，用户就具备了相关的操作权限。

 

其实两者的区别就在于方案一把二维拉平成了一维，假设操作功能用F表示，数据范围用D表示，那么方案一中的权限项会有F * D种。

 

总结

方案二的优点是：将操作功能和数据范围分为两个维度管理，分别用角色权限和职位管理，清晰易扩展。它的缺点就是，对用户来说有点繁琐，需要在两个地方（角色、职位）定义。