Linq-to-sql datacontext类设计问题？

Question

我只在web场景中使用linq-to-sql。我知道建议总是在使用中包装数据上下文，但仅在web场景中，我为之设计的那种场景，这真的没有必要，因为每个页面都会在很短的时间内产生和死亡。

考虑到这一背景，我已经研究了一些扩展的linq-to-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。

我希望看到不同的设计解决方案，这些解决方案需要最少的代码，可以以某种优雅的方式解决这个问题。

此外，任何关于对象分层的详细和具体的建议都可能受到重视。这可能是一举两得。

Answer 1

您确实应该通过System.Web.Security.MembershipProvider类原生提供的方法来操作成员资格。不建议直接操作ASP.NET成员数据库中的数据库表。

如果您想要将System.Web.Security.MembershipProvider包装在您自己的自定义类中，这是很好的；事实上，ASP.NET MVC这样做正是为了使执行单元测试更容易。但这并不是真正的DataContext。