Question

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

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

1 个答案: