作者:lemonade 来源:博客园 发布时间:2011-02-23 16:13 阅读:125 次 原文链接 [收藏]
前言
上篇文章组织结构与权限模型设计(一)中,介绍了权限模型的第一种实现方案,即用户与角色关联、角色与权限关联,职位作为用户的一个标签显示,不涉及权限。这种方案存在一个问题,通常我们说的权限,其实是包含两个维度:操作功能和数据范围。比如学校班级的班长有检查同学作业、布置任务的权利,这是说他能操作的功能;另外,班长只对本班级的学生有布置任务的权利,这里是对数据范围的限制。
方案二
基于上面的分析,可以认为权限是由操作功能和数据范围两个维度组成的,角色定义用户的操作功能,职位定义数据范围。在一个企业里面,不同部门的部门经理虽然职位是一样的(都是部门经理),但是他们所能做的事是不一样的:开发部的经理管项目开发事项、财务部的经理管理财务收支,映射到系统中,就是说他们的操作功能不一样。
相对第一种方案,模型没有发生变化,唯一改变的是对权限和职位的定义不一样了。
对于职位:在方案一中,职位只是作为一个标签显示,不带任何的语义,但是在方案二中我们需要用职位去管数据范围。要知道程序并不知道部门经理能够管理部门成员,对它来说这只是两个不同的字符串而已。有人可能会提出,程序加个if..else判断不就得了,但是要知道企业里面职位是五花八门的,有的公司可能叫部门经理为主任。为了应对这种可变性,我们需要对职位增加一个语义,告诉程序哪个职位是管理者,哪个职位只是普通成员。我们暂且叫这个语义为power,它有两个选择:Manager或Member。将这个语义属性附加到职位上,Manager是具有管理权限的人员,它能够管理本领域内的事项(领域的概念在上一篇中已介绍过)。
对于权限:在方案一中,没有将权限细分为操作功能和数据范围两个维度,权限既管操作功能也管数据范围。在方案二中,权限只定义操作功能,数据范围由职位决定。
打个比方,对于查看工作日志这个功能。
按方案二实现的话,系统中会有一个权限项,叫查看工作日志(操作功能),至于查看谁的工作日志(数据范围),则依据成员的职位,如果他是部门经理,则能查看整个部门的工作日志,如果他是普通成员,则只能查看自己的工作日志。将权限项赋给一个角色,再将这个角色和职位赋给用户,用户就具备了相关的权限。
按方案一实现的话,系统需要两个单独的权限项,叫查看部门成员工作日志、查看自己的工作日志。这两个权限项既定义了操作功能(查看日志),又定义了数据范围(看谁的日志)。将权限项赋给一个角色,再将这个角色赋给用户,用户就具备了相关的操作权限。
其实两者的区别就在于方案一把二维拉平成了一维,假设操作功能用F表示,数据范围用D表示,那么方案一中的权限项会有F * D种。
总结
方案二的优点是:将操作功能和数据范围分为两个维度管理,分别用角色权限和职位管理,清晰易扩展。它的缺点就是,对用户来说有点繁琐,需要在两个地方(角色、职位)定义。