这两天忙着做手头的一个项目，ASP.NET的，没太多技术难度。但做项目通常能让我在思考实现的过程中，冒出各种各样的想法...
为了在ASP.NET 1.1里面实现类似2.0里面的Membership（用于用户的身份验证Authentication）和Role Manager（用于用户的权限验证Authorization）模块，我认真将2.0的文档里面相关的部分看了一遍，然后在1.1里面几乎依葫芦画瓢的实现了出来。在实现的过程中，我渐渐感到Membership和RoleManager的实现方式很是眼熟，然后，我越来越觉得它们的概念非常像一样东东：SOA！
随便写个例子吧，想象一下我们通常如何设计User类和Role类：
class User {
RoleCollection Roles;
}
class Role {
UserCollection Users;
}
各个类之间都有Association。于是，我们用User.Roles来获得一个用户的角色信息，用Role.Users来获得一个角色下有哪些用户。
或者：
class User {}
class Role {}
ICollection RoleService.GetRolesFromUser( String username );
ICollection RoleServie.GetUsersFromRole( String roleName );
void RoleService.AddUserToRole( String username, String roleName );
各个类之间没有Association，我们通过一个（或几个）相关的ServiceFacade来获取相关的信息和进行相关的操作。
Membership和Role Manager就是用的类似于第二种的方式来实现的。好处？Membership和RoleManager之间完全各自独立，两者之间没有直接的联系，没有“依存”关系。比如，我们可以让Membership用AD集成的方式来进行用户认证，但是用户的角色、权限信息则放在SqlServer的表里面。
各个Domain Model的独立，还带来了更多的好处。1、在用ORM（或者手工）载入Entity的数据的时候，因为各个Entity之间被设计成没有Association，所以，我们可以暂时抛开令人烦恼的Lazy-Loading的问题。2、Entity完全可以通过WebService传递到远程，如果有各种Assocation，想象被传递到远程的User实体被直接调用User.Roles将是件多么令人烦恼的事。
但是，别忘了Membership和Role Manager从逻辑上来说，是完全可以分开的，而通常很多东西，天生就是结合非常紧密的。比如：Order和OrderDetail、OrderDetail和Product。
总之，程序员的一大工作就是：Do right thing in right place！