【自然框架】之通用权限：有ER图和表关系图 （收藏）

1、 抽象——总体思路。

先看这个ER图。
【图一】

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

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

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

2、 加入权限

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


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

3、 加入角色

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


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

4、 表关联图

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


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

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

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

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

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

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

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

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

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

      我上面的猜测不夸张吧。

 
5、 何为“资源”

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

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

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

 

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

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

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

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

 

7、 全家福
【图七】


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

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

  

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

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

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

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

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