linq-to-sql datacontext類的設計問題？

我只在web場景中使用linq-to-sql。我知道建議始終將datacontext包裝在使用中，但僅限於web場景中，這是我正在設計的場景，這並不是必須的，因爲每個頁面都會在很短的時間內產卵並死亡。linq-to-sql datacontext類的設計問題？

在這種背景下，我已經看了一些擴展我的LINQ到SQL類的這樣

public partial class aspnet_User 
{ 
    MainDataContext _dc = new MainDataContext(); 

    public MainDataContext DataContext 
    { 
     get 
     { 
      return _dc; 
     } 
     set 
     { 
      _dc = value; 
     } 
    } 

     public static aspnet_User GetUser(Guid guid) 
     { 
     //Here I load the user and associated child tables. 
     //I set the datacontext for the aspnet_User with the local DC here 
     } 

     //_dc.SubmitChanges() 
     public SaveUser()

所以，這是設計的結構，我使用，它似乎很好的工作我的情況。我的問題的一部分是我使用這個內置的成員資格結構，並試圖添加到它更容易，然後重新創建自己的，但有一定的限制。當然，對象的接口的確切組成並不理想，因爲一些功能是跨越數據庫表分層的，無論好壞。

我的問題是，對於一些子對象，如aspnet_Membership，我也擴展了它自己的DC。但是，我沒有任何機制可以更新所有兒童DC，而無需手動設置每個兒童DC。

我想看到各種設計解決方案需要最少的編碼，可以用一種有點優雅的方式解決這個問題。

此外，任何關於對象分層的詳細和具體的建議可能會被讚賞。這可能是一箭雙鵰。

來源

2010-06-21 Curtis White

你真的應該通過System.Web.Security.MembershipProvider類本身提供的方法操縱成員。不建議直接操作ASP.NET Membership數據庫中的數據庫表。

如果你想在自己的自定義類中包裝System.Web.Security.MembershipProvider，那很好;實際上，ASP.NET MVC確實可以使它更容易執行單元測試。但是，這不是一個真正的DataContext。

來源

2010-06-21 22:03:52

是的，我也這樣做了，但決定使用linq-to-sql功能對於某些任務，特別是查詢來說很方便。我決定使用DRY原則之後的基類linq-to-sql類，而不是僅爲結果創建類。現在，我想起它嗯。我會留下來，因爲DC是一個可以解決的更普遍的問題。 – 2010-06-22 18:47:30

linq-to-sql datacontext類的設計問題？

回答

相關問題