Rick Strahl has a nice article about your options: http://www.west-wind.com/weblog/posts/246222.aspx.
See also: LINQ to SQL – where does your DataContext live?.
You may want a slightly different strategy for each type of deployment – web, desktop, windows service…
Summarized, your options are:
- Global DataContext – dangerous in multi-threaded environments (including web apps). Remember that instance members are not guaranteed to be thread-safe (from Bradley Grainger’s answer above).
- DataContext per thread – complicated. If your DataContext is tracking changes you must be sure to flush them at the appropriate time. Instantiating, storing, and retrieving the DataContext is a pain.
- DataContext per atomic action – you lose the ability to track changes since one DataContext creates an object while another updates or deletes it. Attaching a data object to a new DataContext may not work like you expect.
- DataContext per data object – seems inelegant because you have to fuss with the DataContext on instantiation(create and attach) and update/delete (pull it off the data object and use it).
I opted for a DataContext per data object. It may not be the fanciest solution but it works in all deployment environments.