Take the 2-minute tour ×
Stack Overflow is a question and answer site for professional and enthusiast programmers. It's 100% free, no registration required.

I have a project on MVC. We chose EF for our DB transactions. We created some managers for the BLL layer. I found a lot of examples, where "using" statement is used, i.e.

public Item GetItem(long itemId)
    {
        using (var db = new MyEntities())
        {
            return db.Items.Where(it => it.ItemId == itemId && !it.IsDeleted).FirstOrDefault();
        }
    }

Here we create a new instance of DBcontext MyEntities(). We using "using" in order to "ensure the correct use of IDisposable objects."

It's only one method in my manager. But I have more than ten of them. Every time I call any method from the manager I'll be using "using" statemant and create another DBcontext in the memory. When garbage collector (GC) will dispose them? Who knows?

But there is another alternative of usage of the manager methods. We create a global variable:

private readonly MyEntities db = new MyEntities();

and use DBcontext in every method without "using" statement. And method looks like this:

public Item GetItem(long itemId)
{
    return db.Items.Where(it => it.ItemId == itemId && !it.IsDeleted).FirstOrDefault();
}

Questions:

  1. What is the proper way of using DBcontext variable?
  2. What if we wouldn't use "usage" statement (because it affects the performance) - GC will do all for that?

I'm a "rookie" in EF usage and still haven't found the univocal answer for this question.

share|improve this question
    
Depends how far you want to take it. Ideally you wouldn't instantiate it in your controller at all but instead Inject it (IoC/DI) that way whatever is calling controller (Factory) can determine lifetime of Context. –  Belogix Jul 30 '13 at 10:48
    
Why does it affect performance? Have you measured it, and concluded that your are losing performance? And the GC is not disposing it, you are disposing it yourself since you are using using-statements. –  Maarten Jul 30 '13 at 10:56

1 Answer 1

up vote 3 down vote accepted

I think you will find many suggesting this style of pattern. Not just me or Henk DBContext handling

  • Yes, Ideally Using statements for DBContext subtypes
  • Even better Unit Of Work patterns that are managed with Using, that have a context and dispose the context Just 1 of many UoW examples, this one from Julie Lerman
  • The Unit Of Work Manager should be New each Http request
  • The context is NOT thread safe so make sure each thread has its own context.
  • Let EF cache things behind the scenes.
  • Test Context creation times. after several Http request. Do you still have a concern?
  • Expect problems if you store the context in static. any sort of concurrent access will hurt and if you are using parallel AJAX calls, assume 90+% chance of problems if using a static single context.

For some performance tips, well worth a read

share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.