LinqToSql declare and instantiate DataContext best practice?

What's the best practice in terms of setting up my DataContext for easy access in my extended LinqToSql classes?

For example, I have a "User" entity in my dbml and I want to add methods to that class like so:

Partial Public Class User

    Public Function GetUser(ByVal UserID as Integer) as User
         'Do Work
    End Function

End Class

In order to access my DataContext I'd have to declare it inside the method like so:

Partial Public Class User

    Public Function GetUser(ByVal UserID as Integer) as User
         Dim dc as New MyDataContext()
         Return (From u in dc.Users Where u.ID = UserID).Single()
    End Function

End Class

I'd like to not have to do that for every single method. Normally (if I weren't extending the LinqToSql dbml classes) I could just do this:

Partial Public Class User
    Private dc as MyDataContext

    Public Sub New()
         dc = new MyDataContext()
    End Sub

    Public Function GetUser(ByVal UserID as Integer) as User
         Return (From u in dc.Users Where u.ID = UserID).Single()
    End Function

    Public Function GetAllUsers() as IEnumerable(Of User)
         Return From u in dc.Users
    End Function

    'etc...

End Class

This would allow me to access the datacontext for each method without having to declare it newly each time. But of course you can't do that because the dbml already has a constructor. And adding code into the dbml always gets overwritten if anything ever changes.

Anyone have any good ideas on how to save myself some excess code here?

TIA!

First, make sure you are disposing your DataContext when you're done! He can be a heavy little bastard (edit not heavy to instantiate, but heavy to keep around if you keep using it without disposing); you don't want old DataContexts hanging around in memory.

Second, the DataContext is intended to represent a single logical transaction. E.g. you should create a new one every time you want to start a new transaction, and get rid of it when that transaction is complete. So for your purposes, that is probably the scope of the GetUser method. If you have a series of DB calls that need to be made as a group, they should all use the same DC before getting rid of it.

As Rex M said, the datacontext is intended to be instantiated, used, and disposed for each logical transaction. Patterns like this are sometimes called a "unit of work".

The most common way (that I know of) to do this is to instantiate your datacontext in a using block. I haven't used VB in a while, but it should look something like this:

Using dc As New MyDataContext()
   user = (From u in dc.Users Where u.ID = UserID).Single()
End Using

This not only reinforces the look of a transaction/unit of work (through the physical shape of the code), but it ensures calling Dispose() on your datacontext when the block ends.

See this MSDN page:

In general, a DataContext instance is designed to last for one "unit of work" however your application defines that term. A DataContext is lightweight and is not expensive to create. A typical LINQ to SQL application creates DataContext instances at method scope or as a member of short-lived classes that represent a logical set of related database operations.