CODEWITHSUNDEEP
asp.netentity-frameworklinq-to-entities
bugfixr
bugfixr

Reputation: 8077

Entity Framework: What negatives can I bump into by not disposing of my object context?

EDIT: Duplicate of Should Entity Framework Context be Put into Using Statement?

I've been tossing around this idea for some time wondering what bad could happen by not properly disposing my object context and allowing it to die with the GC. Normally, I would shun this, but there is a valid reason to do it.

We are using partial classes. In those partial classes we expose properties that access FK objects. For example, let's say I have a Customer class with a CustomerType FK object. In the class, I would expose a CustomerTypeName property that does this:

public string CustomerTypeName {
  get {
     if (CustomerType == null) {
         CustomerTypeReference.Load() 
     }

     return CustomerType.CustomerTypeName;
  }
}

This works out very handy if the original query did not do a .Include("CustomerType").

However, if I dispose the context, the above property no longer works. So... I guess this leads to a couple of questions:

1) If I never explicitly dispose of the context, what negatives will I see, if any?
2) Is there any other way to accomplish lazy loading in the above scenario and still dispose of the context?

Upvotes: 0

Views: 1146

Answers (3)

Alex James
Alex James

Reputation: 20924

Well ObjectContext's that are left around indefinitely are fine, so long as you don't keep loading / adding lots of new objects.

Every object that is loaded or added will always be tracked by the ObjectContext until it is disposed, so if you never dispose, and you keep tracking more objects it will just get bigger and bigger.

One option you could look at doing is using some utility method to either access some well known context or create a temporary context.

The key to this is using the EntityReference.EntityKey and making sure both entities are detached.

i.e.

this.CustomerType = Utility.GetDetachedObjectByKey<Customer>(
       this.CustomerTypeReference.EntityKey);

The basic implementation of GetDetachedObjectByKey is something like this:

public static T GetDetachedObjectByKey<T>(EntityKey key) 
     where T: EntityObject
{
    using (MyContext ctx = new MyContext())
    {
        T t = ctx.GetObjectByKey(key) as T;
        ctx.Detach(t);
        return t;
    }
}

This will only work if the original object target is detached too. You could experiment with where the Context used by this method comes from.

Hope this helps

Alex

Upvotes: 2

Robert Paulson
Robert Paulson

Reputation: 18061

In my answer to 'LINQ to SQL - where does your DataContext live?' we have the page as owner of the DataContext for the life of the page, and it is the page that properly disposes of the DataContext when the page is itself disposed of.

As @Chu points out it's a little dirty, but if you're going to use what is arguably a data transfer object directly in your UI, then your UI should control the lifetime of the DataContext.

Upvotes: 3

Andrew Burns
Andrew Burns

Reputation: 14509

Why not keep the context around for the length of your screen?

Upvotes: 0

Related Questions