【自然框架】之通用权限:有ER图和表关系图 (收藏)

1、 抽象——总体思路。

先看这个ER图。
【图一】

      很简单,就是说明一下人员和资源的关系,一个人可以使用多个资源,一个资源可以被多个人使用,就是多对多的关系了。这个就是所谓的权限吧。

      不知道这个是不是可以叫做“抽象”。这个就是在金字塔的顶端来看权限了,站在顶端来看,就这么一点,估计没有那种情况可以逃出这个描述吧。

      资源:这里指的资源是广义上的资源,包括很多的东东,模块、数据、记录,菜单、节点、按钮、控件,表、字段、存储过程、SQL语句、查询条件,页面、窗口、表单、图表、报表,什么都可以算作是一种资源。您也可以把您遇到的一些情况都来算作是一种资源。关于资源先说这些,下面还有详细的说明。


2、 加入权限

      第一个图也太简单了,我们把他详细一下,把人员分成两个表——人员基本信息和登录信息,在加入“权限”。就是下面这个表了。
【图二】


      人员分成两个表可以应对很多的情况,比如一个人可以有多个登录帐号,人员基本信息还可以和其他的表相关联,登录方面的需求有什么变化的话,只需要修改登录信息表就可以了,不会影响人员基本信息表,不会让其越来越臃肿。
      以前对于“权限”是很模糊的,似有似无的感觉,现在看来他其实就是一个多对多的关联表,呵呵。当然您可以说我的这个看法不对,呵呵,我只是说一下我的感觉。

3、 加入角色

      第二个图,是把帐号的资源直接联系起来,这个有一个不方便的地方,比如有五个业务员他们的功能都是一样的,但是我们却需要做五遍一样的操作才能给这五个业务员设置好权限,而当业务员可以做的事情有变化的时候,我就又需要做五次相同的操作,这个就很麻烦了,所以引用了“角色”。
【图三】


      我们可以建立一个业务员角色,设置业务员角色可以做的事情,然后把五个业务员和业务员角色关联起来。这样就方便了,业务员可以做得事情有变化的时候,我只需要修改业务员角色可以做得事情就可以了。
     

4、 表关联图

      我觉得ER图就是ER图,不能代替表关系图,所以我就又做了一个表关系图。
【图四】


      左面从上往下看,人员、登录帐号、角色、资源,右面是两个多对多的关联表。这个看起来就比较清晰了吧。

      这个设计还可以吧,资源保罗万象什么都可以往里放,您可以展开您的联想,帮想到的东东都放进去就可以了。

      这个图从设计的角度来说应该是挺简洁的,五六个表就搞定了。而且也可以适合很大的范围,因为那个资源的定义实在是太广泛了,到了无所不包的程度了。但是这个设计真的好吗?或者是实用吗?

=================================================
插播一个笑话

甲:把大象关冰箱里需要几步?
乙:三步,把冰箱门打开,把大象放进去,把冰箱门关上。
甲:回答的很好。现在我这里有一头大象,你把它给放到冰箱里面吧。
乙:…… ……

计划归计划,实现归实现,往往计划的挺好,但是到了实施的时候就会遇到很多的问题。比如大象太大了,冰箱太小了,放不下呀?是不是要把大象给切了,或者定制一个大个的冰箱??

这个就是在做计划的时候没有考虑到细节,没有考虑到可能遇到的难题,想当然了。

=================================================

      回归正题,如果我把这个权限的设计交给十个人,让他们用代码的方式来给实现出来,会是什么情况呢?
      有两个人一头雾水,不知道该如何下手,不知道资源到底是什么,要做到什么程度。
      有七个人开始动手,结果做出了七种实现方式,保证随便选两个都是不一样的。
      剩下的一个人,他已经构思出来了第50种具体的实现方案,但是不知道选哪一种好,都被推翻了,正在构思第51种实现方案。

      我上面的猜测不夸张吧。

 
5、 何为“资源”

      既然上面的设计有点粒度太大了,那么应该怎么办呢?其实也只是“资源”这个表太模糊了,问题就出现在这里,那么是不是要把这个“资源”给详细化一下呢?规定一下这个资源到底是什么,到底是什么样子的,应该在编码的时候如何去实现这个资源?这个恐怕每个人的想法就有都不一样了,这个就没有对错之分了,只有适合不适合的问题。下面我就说一下我对资源的详细设计,这个只是我的想法和理解,并不是唯一的方法。

      这个资源,到现在我都没有敢展开来,为什么?怕大家不接受,说我的表又多了,设计又复杂了,不通用了,不对了等等。所以放在后在展开来的。
【图五】



      这个是自然框架里面需要的资源,功能节点可以生成树状菜单,功能按钮是列表页面里的按钮(添加、修改、删除等),可以设置各种各样的按钮,不只限于添加、修改。每个列表页面都有自己的按钮,按钮是不重复的。
      这个其实和权限是没有什么关系的,就是说没有权限他们也是存在的,也是必须的。通过这些资源就可以做到功能到节点、功能到按钮、功能到字段。

 

      关于模块,我觉得模块就是若干功能节点的集合。

      那么功能节点是什么呢?看下面的图,就是左面的那个功能菜单。角色管理、登录帐号、登录日志、操作日志等是一个个小的功能节点,他们几个和在一起就是一个“系统管理模块”。





6、 角色和过滤方案
【图六】



      这个图是把角色和过滤方案和在一起了,应该分开的,我这里偷了个懒,截图也不是容易的事情呀,呵呵。看图就差不多理解了吧。

 


7、 全家福

【图七】


      把这几个图和在一起,来个全家福。现在您不会觉得表多了吧。

      这个就是比较详细的设计了,看了这个设计您不会一头雾水,不知如何下手的感觉了吧。也不会有那么多不同的解决方案了吧,因为都被我限制死了,呵呵。您可以说这个设计太死板了,这些就把所有的情况都包含进去了吗?出现了新的情况怎么办?好办,建立新的表就可以了。其实一开始只有角色到节点,角色到按钮的功能,没有权限到字段的功能,没有资源过滤的功能,这两个都是在做项目的时候遇到了具体的问题,才总结加上来的。就是说可以不断的扩展的。

  

ps:
1、请大家注意图七里面的四个大框框(人员表组、角色表组、资源过滤方案、资源),这个就是我所说的“表组”,看这个全家福的时候,第一步映入眼帘的就是这四个红色的大字吧,这个就是要说明我的这些个表是哪些范围的,哪些表在一起表达一个意思。第二步再看框框里面的表。每一个框框里的表的数量就不多了。虽然一共有18个表,但是分成四大部分之后,每一部分的表都不超过10个,这样看起来就很容易了。再看资源的相关的表的时候,不会被人员表干扰,因为他们在两个框框里面。这样就避免了迷宫,避免了复杂的乱七八糟的连线。呵呵。

2、俺英文很烂,所以除了主外建使用了英文单词,其他的就都直接使用中文了,呵呵。我还是觉得看中文舒服:)

3、写这个的目的
 给自己用,工作7年的工作总结、思路总结,四、五个项目的权限的总结。
 和大家分享,交流。看看大家的意见,否则不就更是闭门造车吗?

4、您可能会问,客户的人少,每个人做得事情都不一样,这个怎么办呀?
      这也好办呀,一个人一个角色就可以了。虽然对于这种情况多用了一个角色,有点绕远的感觉,但是总体来说是可以接受的。角色初期设置一下就可以了,角色和人员“绑定”之后,修改角色可以做什么事情,和修改人员可以做什么事情,操作步骤都是一样的。


      您可能又问了,客户是一个很大的公司,设置了n个角色之后,客户提出了一个需求:张三这个人比较特殊,他可以做XX事情,但是有没有对应的角色,也不想再多设置一个角色了,需要直接给张三设置可以做这件事情就可以了。
      这个又要怎么处理呢?是不是要修改表结构了呢?我是不想改的,还是用角色绑定的方法来处理,增加一个“张三专用角色”,这个角色是“隐藏”的,不和其他的角色一样的管理,需要通过对“张三”来管理。这个好像说不太清楚,先这样吧,呵呵。
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值