1
背景，我正在擴展自定義類和額外表的ASP.NET成員資格。工廠模式vs易用性？
ASP.NET MembershipUser具有受保護的構造函數和用於從數據庫中讀取數據的公共方法。我已經用自定義表和相關類擴展了數據庫結構。
而不是使用靜態方法創建一個新成員，如原始API：我允許代碼實例化一個簡單的對象並填充數據，因爲有幾個實體。
原始 模式＃1受保護的構造
> static CreateUser(string mydata, string, mydata, ...)
> User.Data = mydata;
> User.Update()
我的首選 模式＃2公共構造
> newUser = new MembershipUser();
> newUser.data = ...
> newUser.ComplextObject.Data = ...
> newUser.Insert()
> newUser.Load(string key)
我覺得模式＃2能夠更輕鬆，更自然的使用。但方法＃1更原子化，並確保包含正確的數據。
我想聽聽任何關於利弊的意見。我腦海中的問題是，我更喜歡簡單的CRUD /對象，但我也嘗試利用底層API。這些方法不完全匹配。例如，API具有方法，如UnlockUser（）和IsLockedOut的只讀屬性。
我可以看到有幾種可能性。
選項＃1 讓對象保存/加載本身，但需要私有構造函數。
選項＃2 有對象保存/載入本身，而是讓它具有公共構造
選項＃3 一個是創建一個POCO /簡單的CRUD對象，然後有更新數據庫的靜態方法。 ..............
選項＃1 優點：多線程安全的「原子」，對象完整性 利弊：很難用 - >傳遞大量的數據，可能需要創建這就需要包裝，在某些情況下，交易看起來是這樣的凌亂後更新
選項＃2 優點：易於使用，簡單的方法來組織交易 缺點：對象可能會或可能不會進行適當設置
我發現整個會員的東西真的不靈活和令人討厭 - 最後我從頭開始編寫自己的文章比嘗試和攻擊ASP.NET做我想做的事更快。例如，在我們的一個系統中，用戶沒有電子郵件地址，但您必須填寫一個密碼重置才能工作的內容。不要讓我開始無法獲得一個體面的錯誤信息！ – 2010-03-18 15:40:58