数据权限设计初探

李俊杰

概述

在许多项目中，都会涉及到数据权限问题，所谓数据权限是表示，在系统中即使角色相同，都有操作权限，但业务操作时受风险、额度、销售区域等业务属性限制。

如销售人员可以看到自己的销售列表，而销售经理可以看到其管辖范围内的销售人员的销售列表，而高级销售经理能看到其下辖的销售经理的销售列表，更进一步，只看金额超过1000万的单子，小于1000万的单子不看。如销售人员是销售产品的，但由于产品属性的不同，如产品属性中销售地区在“苏杭地区”，则北京地区的销售人员则不能销售。如产品属性中风险属性高，则销售人员的级别也要求高，则低级别的销售人员则不能销售该产品；进一步来讲，随着时间或形势的发展，该种产品的风险并没有那么大，低级别的销售人员也可以销售；或者该种产品低级别的销售人员销售该种产品的金额小于100w，而高级别的人员销售100w等等。

架构分析及设计

在设计之初就确定了数据权限所处的位置，和操作权限类似，操作权限一般是放在MVC的controller层，作为插件来控制是否有操作权限。数据权限也可以这样设计，但数据权限更多地是和业务逻辑纠缠在一起，因此数据权限可以作为插件放在业务层（Model），更优雅的设计是以模板模式在业务缺省实现基类中，作为过滤。如下图所示，BizClass其实代表业务层的复杂设计，在做分析设计的过程中，我的经验是尽最大可能理解需求，并尽最大可能直白地把需求展现出来，而不是在设计之初先定义什么设计模式，设计模式是在搞清楚需求并能够给出较完整的设计思路后才考虑的。当然，在设计之初也要首先定义其所在软件架构的位置。

从需求方面讲，要达到根据操作人就能够给出该操作人的数据权限，包括查询的详细程度及数据操作规则等。从这儿我们就可以分析出来要获取数据权限，有两个参数userId,

bizName。

其实任何业务需求的设计的途径都是类似的，都是“来料加工”，有原材料，有目标成品，然后把原材料加工成目标成品。当然在其中要考虑很多因素，面向对象的设计思想很重要，不要在设计之初就考虑要多少个表，表之间的关联关系，什么一对多，多对多，关联表。首先要考虑需要业务上有那些需求，这些业务功能如何转变成某些用例，这些用例是如何转换成若干的业务类，这些类有那些属性或方法来实现这些业务功能。而表仅仅是某些实体类的数据存储，不能表现为业务逻辑。也很难体现设计者的思路。

组织机构与（岗位VS角色）

系统设计中，往往会把操作权限和数据权限混为一谈，使用角色权限来控制，这其实就走入了误区，因为操作权限是解决能不能做的问题，数据权限是解决做多大幅度问题。因为角色是没有级别概念的，也就是说没有上下级概念的。

因此在计了“岗位”的概念，岗位是分级别的，且上下级汇报关系的，在这儿还设计了区域（region）属性，是基于某些需求需要，这样设计是基于有些公司的管理是分为矩阵式管理，既有部门，也根据产品线分为事业群管理的。

如下图所示，组织机构是分上下级的，组织机构中包含若干岗位，因工作职责定岗，用户是属于某个岗位的。这就和原来的设计中组织机构和人的关系中增加了岗位的中间层，也就是说，组织机构中只包含其业务中需要设置的岗位，这些岗位由人员来充实，换句话说，组织机构中不养闲人，呵呵！

岗位中一个重要的概念是资源管理，为了简化设计，某一个岗位只是为处理单一的某个业务所设置的，其中bizes属性表示该岗位所涉及的业务有若干的资源。

业务资源与数据权限规则

这组类的主要功能是完成原材料的准备及数据规则与岗位的映射，其中并没有实体类参与，这些类背后需要数据的支撑，到这时再考虑数据存储不迟。例如BizDatRuler后面就需要实体类，可能是多个相关表的数据。

类Resource中包含多个产品的数据权限规则，在ProductInfo其中dataRulers表示（key=positionGrades value=BizRuler），在类BizDataRuler 属性positionGrades 如：3，4，5，6，以逗号分隔，表示某个规则适用与某些级别的岗位，属性productRulers的HashMap<String productAttr,String scope>,其中scope中关于数字范围用“[()]”表示，“[”表示大于等于，“(”表示大于，“）”表示小于，"]"表示小于等于，如“[300,550）”表示大于等于300，小于500。如果是散列数，用“{}”表示，如“{30,50,70}”表示只有属性等于30，40，50的才有数据权限，如“{上海，苏州，杭州}”在表示只在上海，苏州，杭州有效。这就类似与格式化文本的处理方式，简化了文本解析。