[导入]和Reference讨论权限问题

没想到我抛出的一块砖，引来了Reference的一块玉（说完以后，自己都觉得假 ：P）。道出了一些我的困惑。毕竟没有完美的权限系统，需要在易用性和灵活性之间做出取舍。
就Reference提出的几个问题在这里讨论一下，顺便又过一次自己的设计。
1.关于权限冲突.
   中间提到了若两个设置之间互相冲突，在角色中规定可访问的资源，在用户组中却没有和相关的资源对应。但是在我们现有的权限系统设计中却不会出现上面的冲突。因为角色只和操作（比如删除）还有操作的资源类型（比如病历），而用户组则规定了访问该类型资源的范围。比如，规定了该用户可访问的用户组--儿科医生组，那么这个和他的角色权限结合起来，就成了最后的结果--该用户可以删除（操作）儿科医生们（范围）的病历（资源）。这样的话，就不会出现reference提到的问题了。也不知道，我理解对了reference兄的意思了没。
   说道这里，出现了一个问题，正如Reference所说的，访问范围的问题---“假设"门诊部"是"住院部"的一个子部门,如果用户A有权限管理"住院部",那么有权限管理"门诊部"么。这确实是个问题，因为倘若规定父范围包含了子范围，这种大规模的粗放的权限继承，让赋权变得简单，也有显而易见的坏处，不易于灵活控制，比如总公司的一个资源，某个子部门是不能看到的，相似的需求在这种权限策略中实现是颇费一番工夫的，如上例中，你就需要把总公司下的子部门中有权限的分别勾选上，而不是原来的只要勾选上总公司就可以了，增加了赋权的复杂度。
  但是如果，访问范围的权限没有继承的性质，这个做起来灵活度非常高，但是你将会给每一个需要权限的用户组赋权，赋权将会是一场噩梦，系统管理员会被繁琐的操作所淹没。所以我还是比较倾向于带有继承性质的组权限管理模式。细微的权限控制可以在子模块的代码中去实现，权限系统提供必要的调用供各个子系统使用。
    角色也是一样具有继承的性质，子角色自动获得父角色的所有权限。。。

2.关于系统效率
    没有什么太好的招数，根据以前的经验就是缓存、缓存再缓存（和linkin的意见基本一致）。在系统第一次访问的时候，将一个多维的权限表在服务器端缓存起来。客户端每个窗体，在加载的时候请求一次自己的权限信息，作出判断 。这种做法在以忘的经验中至少没有造成什么性能上的麻烦。不方便的就是缓存都有的问题，不能及时体现变化，需要一个合理的刷新机制。这个问题我想作为整个企业框架缓存机制的一个方面来处理，单就权限系统将不再这方面作太多的考虑。

3.HP OPENVIEW 的 IT管理平台中的权限管理界面示意图:
    虽然没有看reference上传的图，但是可以想象其大概的样子，在资源和操作的交汇处，点上一个勾勾，就具有了对某资源的某操作。确实非常直观，非常感谢Reference兄的建议。

文章来源:http://www.agilelabs.cn/blogs/wind_tower/archive/2005/11/10/170.aspx