views:

643

answers:

2

Hi there,

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 IUnitOfWork 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

thanks

Toby

+2  A: 

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

Michael Ulmann
Icky. Components should not depend on the container, they should depend on their actual dependencies.
Aaronaught
sometimes it's useful to inject the container, you still have decoupling ;)
Michael Ulmann
In fact in some projects that I have worked on we had a static property representing the IUnityContainer that it could be consumed even without injection.
Michael Ulmann
thanks Michael - that works great, and more than once when I changed the lifetime by getting rid of the ContainerControlledLifetimeManager() parameter.Great, I can go to bed now, thank you to everyone else that answered.Toby
TobyEvans
@Michael Ulmann: That is a well-known **anti-pattern**! Having components reach out to a static container instance is a horrible, horrible thing to do.
Aaronaught
@Aaronaught: If we're talking about composite applications it's common to inject the IUnityContainer into modules or alternatively use a static container. At the end of the day this is just semantics. Have a look at the composite application guideance they recommend to do that too. Funny that these guys from MS are using an anti-pattern as per your post...
Michael Ulmann
Many bad ideas are nevertheless common - see "Singleton", which is exactly what this is. A class that creates its own dependencies via the container is not being "injected" at all, there's no inversion-of-control. When you see this being used, it can almost always be replaced with an Abstract Factory. There are lots of good references on the subject but I'll refer you to Mark Seeman's: http://blog.ploeh.dk/2010/02/03/ServiceLocatorIsAnAntiPattern.aspx
Aaronaught
+2  A: 

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).

Aaronaught
Hi Aaron - you and Michael were both right, it was that naughty little ContainerControlledLifetimeManager that I had hanging around from a previous version. I've removed that, gone back to having IUnitOfWork in the Presenter constructor, and it seems happy enough.thank you everyone, very educational ...
TobyEvans
and the reason I had it in the first place was this question: http://stackoverflow.com/questions/2412563/unity-framework-reusing-instanceHowever, I've now changed my design to use a factory to create my Repositories, and the factory method takes the IUnitOfWork as the parameter:var localCache = cacheRepository.CreateRealtimeRepository(unitOfWork)so I don't need to have the ContainerControlledLifetimeManager Like I said, very educational ...
TobyEvans