views:

485

answers:

3

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?

A: 

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

Andrew Burns
Correct me if I'm wrong, but that would mean I'd have to keep track of the context from my GUI. That feels a little dirty in a layered architecture.
Chu
no more dirty than ignoring it and hoping it'll go away :)
gbjbaanb
You are interacting with it from the GUI anyway. By disposing it you are telling the resource that you are done with it. By definition if something might lazy load you are not yet done with it. You could even create a simple IComponent wrapper and just add it to your forms Components and it will get cleaned up without another worry or line of code form you.
Andrew Burns
@gbjbaanb - Touche :p
Chu
+3  A: 

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.

Robert Paulson
I do the same thing. I use a base Page that inherits from System.Web.UI.Page. It has a DataContext property that ensures a single instance across the lifetime of the page. (Will share code if requested.)
Matt Sherman
+2  A: 

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

Alex James