I had an MVC application using Unit of Work, Generic Repository and Unity. I called the Unit of Work class directly from my Controllers, and I was a happy man, as the Unit of Work pattern worked well, and the Generic Repository saved me lots of redundant code.
As my application evolved, my Controllers grew to become quite fat. So I decided to introduce a Service Layer between the Controllers and the Unit of Work class, which hooked up to my Generic Repository.
I created a Service per entity, as that was suitable for my application. The problem came clear quite quickly. Before I worked on the same Unit of Work, and therefore also the same database context, because all the magic started in only one Controller.
Now, after introducing the Service Layer, I had a challenge, as I had a Controller using many different entities pulled from many different Services. As soon as I tried to update and save an entity, and more than one service was involved in the operation, my Generic Repository threw an exception:
The relationship between the two objects cannot be defined because they are attached to different ObjectContext objects.
The specific codeline, where the error occured was when setting the EntityState to Modified:
public void Update(TEntity obj)
_dbContext.Entry(obj).State = EntityState.Modified;
The problem is that Unity is told to create a Unit of Work more than once, so when doing an update on an object, the object is attached to different datatbase contexts. Why did this problem come when introducing the Service Layer? Well, that is because the way I introduced the Service Layer, I would end up creating a Unit of Work per Service class, as each Service class had a Constructor creating a Unit of Work object:
public class ExampleService : IExampleService
private readonly IUnitOfWork _unitOfWork;
public ExampleService(IUnitOfWork unitOfWork)
_unitOfWork = unitOfWork;
I could have newed up a single Unit of Work or a single context class from the Controller, and then used that when creating my services, which again would use this single Unit of Work or context class, when creating the Generic Repository. But that solution would be really ugly and I would be moving away from the beauty of Unitys way to solve dependency injection. Lots of refactoring would be involved, and my code would be harder to unit test.
After many hours, I found that the solution was so simple. Unity provides something called a hierarchical lifetime manager.
When you use the RegisterType method on the Unity Container, the default lifetime manager is the TransientLifetimeManager. The TransientLifetimeManager manager returns a new instance of the registered type on each request. So as I had a Unit of Work created in each Service class, I would end up with the same amount of Unit of Work objects, as the Services involved in my update operation. Each Unit of Work would create a database context, and I would end up with the object I wanted to update having several database contexts. This was not what I wanted.
I changed the registration of my Unit of Work to use a Hierarchical Lifetime Manager, to see if I would the end up with one, and only one, Unit of Work:
container.RegisterType(typeof(IUnitOfWork), typeof(UnitOfWork), new HierarchicalLifetimeManager());
The outcommented line was how I done it initially. By using the Hierarchical Lifetime Manager, any resolution of the registered type will give me a singleton instance which is scoped to the lifetime of my container.
Problem was solved. I am now able to use as many services as I like.
I really hope I can help somebody with this blog, as I lost many hours finding this simple solution.
Feedback for improvements on my explanation is much appreciated.