Linq-to-sql datacontext class design question?

Question

I'm using linq-to-sql in a web scenario only. I know it is recommended to always wrap the datacontext in a using but in a web scenario only, the kind of scenario I'm designing for, this is really not necessary because each page will spawn and die in very short time.

Given that background, I've looked at extended some of my linq-to-sql classes as such

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()

So, this is the design construct I've employed and it appears to work well for my case. Part of my problem is I'm using this built-in membership structure and trying to add to it which is easier then recreating my own but has certain limitations. Granted, the exact composition of interface to the object isn't ideal because some the functionality is stratified across the database tables, for better or worse.

My question is, for some of the child objects, such as aspnet_Membership, I've also extended that with its own DC. But, there is no mechanism yet for me to update all the childrens DC without setting each manually.

I'd like to see various design solutions that require a minimum of coding that could address this in a somewhat elegant way.

Also, any detailed and specific suggestions about the stratification of the objects might be appreciated. This could be a kill 2 bird with one stone.

Answer 1

You really should manipulate the Membership through the methods provided natively by the System.Web.Security.MembershipProvider classes. It's not advisable to manipulate the database tables in the ASP.NET Membership database directly.

If you want to wrap the System.Web.Security.MembershipProvider in your own custom class, that's fine; in fact, ASP.NET MVC does exactly that to make it easier to perform unit testing. But that's not really a DataContext, as such.