LINQ to SQL - where does your DataContext live?

Question

I'm using LINQ to SQL in a data access object library. The library is used in both web (web application/web service) and non-web (windows service) contexts. Initially, I stored the DataContext on the current HttpContext since it permitted me to manage a fairly small unit of work (one web request) and avoided global objects in a web app. Obviously, this doesn't work in a Windows Service.

Rick Strahl has a nice article on managing the DataContext's lifetime: http://www.west-wind.com/weblog/posts/246222.aspx. Unfortunately, I can't make up my mind on the best approach. A global DataContext doesn't work for reasons he mentions, a per-Thread DataContext seems complicated and potentially more trouble than it's worth, and a per-object instance seems fussy - you lose some elegance when you attach the DataContext used to create a DAO to that DAO so it can update or delete later - not to mention, there's something unpleasantly chicken-and-eggish about the relationship.

Does anyone have personal experience that suggests one approach is better than another? Or better yet, does anyone have a fourth or fifth approach I'm not seeing? Where is the best place to store and manage your DataContext?

Answer 1

The guidelines from the MSDN documentation on the DataContext class are what I would recommend following:

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.

Because DataContext is IDisposable, I find it easiest to create and use a DataContext in a using statement within one method, so it can be disposed of properly.

Also note that "any instance members are not guaranteed to be thread safe", so sharing one DataContext between multiple threads would be unwise.

Answer 2

I'm using a per-thread context. It is tricky to setup, but it cleans up everything that needs to talk to the db.

Answer 3

I'm using httpcontext in web scenarios and thread context for everything else. We built a little framework so that the data context would be completely abstracted from the presentation/business tier.

Answer 4

Dependency Injection.

We prefer to keep our business layer ignorant of web vs non-web scenario's. Instead, business logic layer objects take a DataContext reference in their constructor which (explicitly) allows sharing the DataContext and (implicitly) allows sharing of the entity objects from query results as they are all from the same data context.

Also DataContexts implement IDisposable, so you really need to manage their lifetime. All our web forms have a base class, and part of that is a datacontext property (lazily created). That way everything on a page can share it, which is most often the case. The context is disposed of manually in the page's OnUnload() event.

---

• You shouldn't mix linq entities from from different data contexts, and you typically get into trouble if you use the linq entities if the datacontext has been Dispose()'d of.