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类的设计问题？

回答

相关问题