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.
与恶龙缠斗过久,自身亦成为恶龙;凝视深渊过久,深渊将回以凝视…