Unity framework - creating & disposing Entity Framework datacontexts at the appropriate time

With some kindly help from StackOverflow, I've got Unity Framework to create my chained dependencies, including an Entity Framework datacontext object:

using (IUnityContainer container = new UnityContainer())
{
    container.RegisterType<IMeterView, Meter>();
    container.RegisterType<IUnitOfWork, CommunergySQLiteEntities>(new ContainerControlledLifetimeManager());
    container.RegisterType<IRepositoryFactory, SQLiteRepositoryFactory>();
    container.RegisterType<IRepositoryFactory, WCFRepositoryFactory>("Uploader");
    container.Configure<InjectedMembers>()
        .ConfigureInjectionFor<CommunergySQLiteEntities>(
            new InjectionConstructor(connectionString));

    MeterPresenter meterPresenter = container.Resolve<MeterPresenter>();

this works really well in creating my Presenter object and displaying the related view, I'm really pleased.

However, the problem I'm running into now is over the timing of the creation and disposal of the Entity Framework object (and I suspect this will go for any IDisposable object). Using Unity like this, the SQL EF object "CommunergySQLiteEntities" is created straight away, as I've added its interface, IUnitOfWork to the constructor of the MeterPresenter

    public MeterPresenter(IMeterView view, IUnitOfWork unitOfWork, IRepositoryFactory cacheRepository)
    {
        this.mView = view;
        this.unitOfWork = unitOfWork;
        this.cacheRepository = cacheRepository;
        this.Initialize();
    }

I felt a bit uneasy about this at the time, as I don't want to be holding open a database connection, but I couldn't see any other way using the Unity dependency injection. Sure enough, when I actually try to use the datacontext, I get this error:

    ((System.Data.Objects.ObjectContext)(unitOfWork)).Connection 
  '((System.Data.Objects.ObjectContext)(unitOfWork)).Connection'
threw an exception of type 'System.ObjectDisposedException'
 System.Data.Common.DbConnection {System.ObjectDisposedException}

My understanding of the principle of IoC is that you set up all your dependencies at the top, resolve your object and away you go. However, in this case, some of the child objects, eg the datacontext, don't need to be initialised at the time the parent Presenter object is created (as you would by passing them in the constructor), but the Presenter does need to know about what type to use for IUnitOfWork when it wants to talk to the database.

Ideally, I want something like this inside my resolved Presenter:

using(IUnitOfWork unitOfWork = new NewInstanceInjectedUnitOfWorkType())
{
    //do unitOfWork stuff
}

So the Presenter knows what IUni开发者_开发技巧tOfWork implementation to use to create and dispose of straight away, preferably from the original RegisterType call. Do I have to put another Unity container inside my Presenter, at the risk of creating a new dependency?

This is probably really obvious to a IoC guru, but I'd really appreciate a pointer in the right direction.

You don't need to worry about initializing an ObjectContext at the same time that the presenter is created - an ObjectContext does not hold open a database connection. Rather, it opens connections as needed, when it actually needs to talk to the database, i.e. when you execute a query or commit changes, and closes the connection again as soon as it is finished. It will only hold the connection open if you explicitly open it, which is a rare thing to be doing with Entity Framework.

If you're getting an ObjectDisposedException using the ContainerControlledLifetimeManager then it means your container is getting disposed before the presenter, which is a design error. It's not entirely clear what your environment is (ASP.NET? Winforms?), but the ContainerControlledLifetimeManager is probably not appropriate here, as it works as a Singleton instance. Normally you will actually want to create a new context instance when you resolve the type - there are many problems you can and will run into if you use a singleton instead.

So - I would get rid of the ContainerControlledLifetimeManager here, and also make sure that your container is not getting disposed too early; the fact that it's in a using block indicates that this is likely the cause of your ObjectDisposedException. (You still need to dispose the container eventually of course - it's just that you're probably doing something like creating a modeless form, which remains alive long after control leaves the using scope).

Why don't you just remove the IUnitOfWork from the constructor and instead inject the unity container? So you will have the flexiblity to call container.Resolve<IUnitOfWork>() anywhere in your code when appropriate.

Example:

using(IUnitOfWork unitOfWork = container.Resolve<IUnitOfWork>()) 
{ 
    //do unitOfWork stuff 
} 

Don't forget to set the lifetime of the instance to single.

Michael

I know this question is old, but I would still like to give my 2 cents here.

You can register your UnitOfWork abstraction normally, but request a Func<IUnitOfWork> in your class instead of an instance. This is a neat feature of Unity actually, being able to resolve delegates that create your object instead of getting the object right away.

This way, you can do as you wanted to, i.e. control the scope of the unit of work inside your method.

In short:

container.RegisterType<IUnitOfWork, CommunergySQLiteEntities>();

...

public MeterPresenter(IMeterView view, Func<IUnitOfWork> unitOfWorkFactory, IRepositoryFactory cacheRepository)
{
    this.mView = view;
    this.unitOfWorkFactory = unitOfWorkFactory;
    this.cacheRepository = cacheRepository;
    this.Initialize();
}

...

using(IUnitOfWork unitOfWork = unitOfWorkFactory())
{
    //do unitOfWork stuff
}

I've used this a few times already and I personally recommend it, since you still have full control over everything, including mocking for unit testing, while still not coupling your code to anything but it's dependencies.

You could create a IUnitOfWorkFactory interface and inject that instead if you needed more complex logic, but the Func<T> delegate suffices in most cases.