项目进行中...

这两天忙着做手头的一个项目,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!

posted on 2004-06-28 20:12  kaneboy  阅读(138)  评论(0编辑  收藏  举报

导航