Instantiating a context in LINQ to Entities

Question

I've seen two different manners that programmers approach when creating an entity context in their code.

The first is like such, and you can find it all over the MSDN code examples:

public void DoSomething() {
     using (TaxableEducationEntities context = new TaxableEducationEntities()) {
          // business logic and whatever else
     }
}

The second is to create the context as a private attribute in some class that encapsulates your business logic. So you would have something like:

public class Education_LINQ {

        private TaxableEducationEntities context = new TaxableEducationEntities();

        public void DoSomething() {
            var result = from a in context.luAction
                         select a;

            // business logic and whatever else
        }
}

Which way is more efficient?

Assume that you have two methods, one called DoSomething1() and another called DoSomething2(), and both methods incorporate the using statement to open the context and do whatever with it. Were you to call one method after the other, would there be any superfluous overhead going on, since essentially both methods create the context and then clean it up when they're done? As opposed to having just one private attribute that is created when a class object is instantiated, and then in turn cleaned up when the object goes out of scope?

Answer 1

Creating a new ObjectContext each time does involve 'some' overhead. Essentially the overhead involved is copying metadata from a global cache into metadata associated with the specific ObjectContext.

This overhead is relatively minor, so often it is not worth worrying about, especially when you consider the extra safety inherent in the using pattern.

For me which option you choose depends upon things like:

1. How long lived is your wrapping class likely to be? If it lives for a long time the ObjectContext might grow to hold a lot of entities slowing down over time. So a new ObjectContext each time might be a good idea.
2. Are calls to the methods on your wrapping class synchronized? The ObjectContext class itself is not threadsafe so if you use the second pattern you need to make sure your wrapping class / repository is thread safe if you expect multiple threads to call it.
3. Are the methods essentially unrelated? If so you might get unexpected side-effects if they share one context between the methods.

In general my recommendation is that if the methods are stateless, i.e. fire and forget a new context for each method is probably a good idea.

If however you have a relatively short lived stateful form or something then maybe a shared context is a better idea.

UPDATE: I've taken the time to put together a more complete answer