Here's another topic which I believe is important to educate more folks on, but I just haven't had the time to carefully write something up. As I was answering a question on the forum today, I realized that the answer might be good to share a bit more broadly, so here's a copy of that response. The question which has come up several times is "When do I dispose of a context and recreate it vs when should I keep the existing context around and re-use it?"
If you are building a rich client application then you may well want to keep a context around for the life of the application, but you need to keep track of how many entities you have in that context. It's all about understanding the overall pattern of your app. There are some extremes and a whole spectrum of possibilities across the middle.
As one of my high-school math teachers used to say, clear as mud?
PingBack from http://www.biosensorab.org/2008/02/17/context-lifetimes-dispose-or-reuse/
There is an interesting post over at blogs.msdn.com
Comme pour LINQ To SQL, avec l'EF, la gestion du context n'est pas forcément aisée et divise les développeurs.
Isn't that just overly simplistic? There are a number of problems with keeping DataContexts around
including the fact that you can't abort. You have to create a new one to abort changes. If one part of the app relies that the datacontext is sticky and another makes changes that require aborting and firing up a new one, how do you consolidate that? GUI apps are not exactly sequential and operations often occur out of order. If you have some operations that run 'concurrently' (not threaded but in the context of a business that might span several bunsiness objects) how do you consolidate the changes when only a few need to be updated and some thrown away?
The real question is whether is it realistic on both ends of the spectrum to a) keep DataContext spun up all the time and possibly using large amoutns of memory and possible 'data inconsistencies' at the application level or b) keep spinning up new ones and eat CPU cycles in the process.
I think the solution lies somewhere in the middle. Even Web apps that are build with Business Objects will need more than a single DataContext to deal with their own atomic state. Personally I prefer using a per business object DataContext - that way you have logical context with the ability to create additional instances if there's a conflict.
I wrote about context management approaches a while back:
This is a frequently asked question on the forums, and Danny Simmons has now written a helpful blog post
In my ongoing series of trying to repurpose / further broadcast important topics that come up in the
One interesting question customers that are TDD practitioners usually ask is how to do unit testing with
Mike Taulty ponders best practices with the lifetime of a LINQ to SQL DataContext . For the Entity Framework
Here's a collection of  posts about the lifetime of these two related contexts. From Dinesh