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.
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
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With