項目進行中…

這兩天忙著做手頭的一個項目，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！