转载:http://lijj-72.iteye.com/blog/314192
概述
在许多项目中,都会涉及到数据权限问题,所谓数据权限是表示,在系统中即使角色相同,都有操作权限,但业务操作时受风险、额度、销售区域等业务属性限制。
如销售人员可以看到自己的销售列表,而销售经理可以看到其管辖范围内的销售人员的销售列表,而高级销售经理能看到其下辖的销售经理的销售列表,更进一步,只看金额超过1000万的单子,小于1000万的单子不看。如销售人员是销售产品的,但由于产品属性的不同,如产品属性中销售地区在“苏杭地区”,则北京地区的销售人员则不能销售。如产品属性中风险属性高,则销售人员的级别也要求高,则低级别的销售人员则不能销售该产品;进一步来讲,随着时间或形势的发展,该种产品的风险并没有那么大,低级别的销售人员也可以销售;或者该种产品低级别的销售人员销售该种产品的金额小于100w,而高级别的人员销售100w等等。
架构分析及设计
在设计之初就确定了数据权限所处的位置,和操作权限类似,操作权限一般是放在MVC的controller层,作为插件来控制是否有操作权限。数据权限也可以这样设计,但数据权限更多地是和业务逻辑纠缠在一起,因此数据权限可以作为插件放在业务层(Model),更优雅的设计是以模板模式在业务缺省实现基类中,作为过滤。如下图所示,BizClass其实代表业务层的复杂设计,在做分析设计的过程中,我的经验是尽最大可能理解需求,并尽最大可能直白地把需求展现出来,而不是在设计之初先定义什么设计模式,设计模式是在搞清楚需求并能够给出较完整的设计思路后才考虑的。当然,在设计之初也要首先定义其所在软件架构的位置。
从需求方面讲,要达到根据操作人就能够给出该操作人的数据权限,包括查询的详细程度及数据操作规则等。从这儿我们就可以分析出来要获取数据权限,有两个参数userId,
bizName。
其实任何业务需求的设计的途径都是类似的,都是“来料加工”,有原材料,有目标成品,然后把原材料加工成目标成品。当然在其中要考虑很多因素,面向对象的设计思想很重要,不要在设计之初就考虑要多少个表,表之间的关联关系,什么一对多,多对多,关联表。首先要考虑需要业务上有那些需求,这些业务功能如何转变成某些用例,这些用例是如何转换成若干的业务类,这些类有那些属性或方法来实现这些业务功能。而表仅仅是某些实体类的数据存储,不能表现为业务逻辑。也很难体现设计者的思路。
组织机构与(岗位VS角色)
<!----><v:shapetype o:spt="75" coordsize="21600,21600" filled="f" stroked="f" id="_x0000_t75" path="m@4@5l@4@11@9@11@9@5xe" o:preferrelative="t"><v:stroke joinstyle="miter"></v:stroke><v:formulas><v:f eqn="if lineDrawn pixelLineWidth 0"></v:f><v:f eqn="sum @0 1 0"></v:f><v:f eqn="sum 0 0 @1"></v:f><v:f eqn="prod @2 1 2"></v:f><v:f eqn="prod @3 21600 pixelWidth"></v:f><v:f eqn="prod @3 21600 pixelHeight"></v:f><v:f eqn="sum @0 0 1"></v:f><v:f eqn="prod @6 1 2"></v:f><v:f eqn="prod @7 21600 pixelWidth"></v:f><v:f eqn="sum @8 21600 0"></v:f><v:f eqn="prod @7 21600 pixelHeight"></v:f><v:f eqn="sum @10 21600 0"></v:f></v:formulas><v:path o:extrusionok="f" o:connecttype="rect" gradientshapeok="t"></v:path><!----><o:lock v:ext="edit" aspectratio="t"></o:lock></v:shapetype><v:shape id="_x0000_i1025" type="#_x0000_t75" style="WIDTH: 400.5pt; HEIGHT: 202.5pt"><v:imagedata src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\07\clip_image001.png" o:title=""></v:imagedata></v:shape>
系统设计中,往往会把操作权限和数据权限混为一谈,使用角色权限来控制,这其实就走入了误区,因为操作权限是解决能不能做的问题,数据权限是解决做多大幅度问题。因为角色是没有级别概念的,也就是说没有上下级概念的。
因此在计了“岗位”的概念,岗位是分级别的,且上下级汇报关系的,在这儿还设计了区域(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的才有数据权限,如“{上海,苏州,杭州}”在表示只在上海,苏州,杭州有效。这就类似与格式化文本的处理方式,简化了文本解析。
<o:p> </o:p>
<v:shape id="_x0000_i1027" type="#_x0000_t75" style="WIDTH: 404.25pt; HEIGHT: 206.25pt"><v:imagedata src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\07\clip_image005.png" o:title=""></v:imagedata></v:shape>
<o:p> </o:p>
附录:数据权限模块设计类图:
努力,在于我热爱我的事业,与中国的软件一起走向成熟,走向世界。
联系作者:lijj_72@hotmail.com<o:p></o:p>
<v:shape id="_x0000_i1028" type="#_x0000_t75" style="WIDTH: 414.75pt; HEIGHT: 271.5pt"><v:imagedata src="file:///C:\DOCUME~1\ADMINI~1\LOCALS~1\Temp\msohtml1\07\clip_image007.png" o:title=""></v:imagedata></v:shape>
分享到:
相关推荐
做到代码低侵入度,在开发时不需要太多关注数据权限控制,可以在应用开发完成后,通过对表和视图定义权限控制策略,然后绑定到登录用户或功能URI上来进行数据权限控制。数据访问控制需要调整时,只需要修改定义的...
数据权限的实现数据权限的实现数据权限的实现数据权限的实现
通用数据权限管理系统设计定义 本文提供了一种集成功能权限和数据权限的解决方法,以满足多层次组织中权限管理方面的集中控制。本方法是基于角色的访问控制方法(RBAC)的进一步扩展和延伸,即在功能权限的基础上...
一个通用的数据权限管理系统的设计,一个doc文档,大家看了自己研究吧~
帆软报表详细设计,跨境电商数据权限控制,有详细的存储过程,权限控制方案
通用RBAC权限设计及其数据权限和分库分表 支持服务限流、动态路由、灰度发布、 支持常见登录方式, 多系统SSO登录 基于 Spring Cloud Hoxton 、Spring Boot 2.3、 OAuth2 的RBAC权限管理系统 提供对常见容器化支持 ...
芋道管理后台,基于 Vue2 + Element UI 实现,支持 RBAC 动态权限、数据权限、SaaS 多租户、Flowable 工作流、三方登录、支付、短信、商城、CRM、ERP 等功能.zip
JEECG 开发文档系列 ——JEECG 数据权限自定义SQL表达式用法说明
芋道管理后台,基于 Vue3 + Element Plus 实现,支持 RBAC 动态权限、数据权限、SaaS 多租户、Flowable 工作流、三方登录、支付、短信、商城、CRM、ERP 等功能.zip
根据liger ui中的增加条件分组功能,实现的数据权限管理,页面生成json串,通过解析成sql,动态追加到对应的资源查询中,供大家参考
做到代码低侵入度,在开发时不需要太多关注数据权限控制,可以在应用开发完成后,通过对表和视图定义权限控制策略,然后绑定到登录用户或功能URI上来进行数据权限控制。数据访问控制需要调整时,只需要修改定义的...
数据权限设计,集成前端页面,后台数据结构。权限设计,基本参照。仅供学习使用
使用SpringAop使用Oracle数据权限控制
JEECG 数据权限操作手册V3.6.pdf 如果需要的可以下载看看
WEB应用数据权限控制.pdf
芋道管理后台,基于 Vue3 + Element Plus 实现,支持 RBAC 动态权限、数据权限、SaaS 多租户、Flowable 工作流、三方登录、支付、短信、商城、CRM、ERP 等功能。
基于SpringBoot | Mybatis-Plus | RabbitMQ | Vue2 | Element-UI | flowable 的多租户SaaS 开发框架,已支持消息队列、数据权限、动态源、多租户、工作流、数据物理&逻辑双隔离等,为企业级多租户Saas及集团化应用...
JAVA的数据权限设计 JAVA的数据权限设计 序言 在各种系统中,要保证数据对象的安全性以及易操作性,使企业 的各业务部门、职能部门能够方便而且高效的协同工作,那么一个 好的数据权限管理设计就成为一个关键的问题。...
这是一个有关于开发的文档,内容是怎么设计数据权限的。
美团技术沙龙03 - 数据权限管理方案.580f27d0-4fd7-11e6-8998-7f0e79c2a51a.pdf