Linq-to-sql 数据上下文类设计问题？

Question

我仅在 Web 场景中使用 linq-to-sql。我知道建议始终将 datacontext 包装在 using 但仅在 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。

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

此外，任何关于对象分层的详细和具体的建议都可能会受到赞赏。这可能是一石二鸟。

Answer 1

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

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