[导入]修改后的权限人员管理系统设计

有一段时间没有写Blog了，这段时间一直在设计权限和人员管理，希望能做出一个通用性好，具有很好伸缩性的权限人员系统来。所以中间讨论了多次，也反复了多次，同时借鉴了活动目录和模式分析上面的一写东西。终于出了一个阶段性的成果，先把图贴出来给大家看看。

上面的图有点乱，但基本上我觉得还是将设计意图表示出来了，权限是集成到了框架中去的，再好好解释一下，希望大家提出宝贵意见。

首先解释一下“Party”——“团体”这个概念，这个概念从英国国民医疗服务系统中借鉴而来，代表了机构中的组成单元。包括了任何人和组织。因为多数事务都与“团体”相关而不是与个人或是组织相关，比如个人和组织互通邮件；付款给个人或是组织；组织和个人都会产生某些行为，都会有银行帐号，都会缴纳税款，这个就是“团体”概念价值所在了。

在上面的设计中，机构下面会有人，会有组，也会有职位，子机构，这样抽象一个他们的超类出来，这样会给编程带来极大的便利。规划了"Party"类，然后就是设计"OrganizationUnit"组织单元类，"User"用户类，"Group"组类，""Position"职位类，这些类作为基础人员机构管理的一部分，固化在agile Framework 中，做到没有具体的人力资源系统，框架也能提供完善的权限服务，即使有了具体的人力资源子系统，也可以从这几个类继承下来，增加具体的属性就可以了，绝大所数CRUD的操作可以调用框架的PartyManagerService来完成，因为这个服务中的很多是都是范型方法，这样就会有很好的向下兼容性（好像是废话，呵呵）。

这么设计的意图是想把人员管理和人事系统在一定程度上隔离开来，人员管理虽然和人事系统上面有重合的地方，那么就把重合的地方抽取出来，人员管理只管理机构、人员还有职位，具体的人事业务在具体的人事系统实现，但人事系统必须使用人员管理中的人员机构信息（至少实现数据同步），并且最大限度的使用框架中人员管理的相关服务（异构系统的整合，确实是个恼人的问题，目前还不能考虑太多）。

说了很多人员管理的问题，也没办法，没有人员管个什么权限。现在就来说权限的设计，看过我的以前Blog的朋友应该知道，以前的也是说了很多，这次的方案只是略有改动，最大的变化就是把资源和操作组合了起来，做成一个Function——对XXX资源的XXX操作就是一个Function,权限配置的时候将Function赋给Role,再把User加到Role中，这样User就有对XXX资源进行XXX操作的权限了。权限控制的粗细粒度，通过对Function的划分把握来掌控。Role没有什么大的变化，仍然可以继承父角色的权限（只能是单继承），只是现在不能将Group加到Role中，因为那样权限会成一团浆糊，要清楚地弄懂可不是简单的事情，对系统管理员的要求太高，导致系统易用性会降低。所以暂时不考虑这个特性。

Agile Framework将会是个全插件式的框架，怎么解决新加入插件的权限问题呢，当然如果插件都是不需要权限控制的，我会每天给佛祖烧个猪头（佛祖吃荤？）。现实总是残酷的，企业级的应用不需要权限控制的地方少之又少，所以我们订出一个IPlugable等一组接口，每个插入的子系统，都必须实现这个接口，只要实现了这个接口，框架就能通过反射或是其他的机制获得该插件的信息，可能不只包括权限信息，其他插件需要让框架了解到的信息，都可以由相应的接口方法提供。

似乎是该考虑的问题，都考虑了一下，边做边完善吧，把什么都想好再作，可不是敏捷的作风啊！

 

文章来源:http://www.agilelabs.cn/blogs/wind_tower/archive/2006/01/01/444.aspx