Question

I just have a quick question. Im trying to use Unity with my asp.net MVC project. Im coming across a problem when using the Unit of Work pattern with an EF context.

Say i inject the uow in the constructor, but have 4 or 5 actions in the controller that need to use the UnitOfWork in a using statement. This isnt going to work! Because Id have to do a
new UnitOfWork() in each action method.

should i be injecting a UnitOfWork into each action method? or into just the constructor? or should I even be injecting this at all!! The problem im facing is that i want to be able to unit test my controller with Mock data, and i can only do this if I inject the UnitOfWork or the DBContext.

Answer 1

Inject factory instead. This way you still achieve separation of concerns and loose coupling, yet you won’t face any issues with using statements:

private IUnitOfWorkFactory factory;

public MyController(IUnitOfWorkFactory factory)
{
    this.factory = factory;
}

public ActionResult MyAction()
{
    using (var uow = factory.CreateUnitOfWork())
    {
        // ...
    }
}

Edit:

Natural advantage of such approach is its configurability – you can register whichever factory you like to serve different controllers and wire it up at composition root:

// Note: this isn't unity syntax, but I hope my point is clear
container.Register<ISessionFactory, ReusableSessionFactory>("Reusable");
container.Register<ISessionFactory, FreshSessionFactory>("Fresh");
container.Register<IController, LoginController>().With("Fresh");
container.Register<IController, HomeController>().With("Reusable");

Now,

• LoginController will use factory that under the hood serves new session upon each request
• HomeController on the other hand will reuse the same session for all its lifespan

It’s worth noting that from the controller point of view, it’s irrelevant which factory serves the session as it’s a mere implementation detail. That’s why we hide session factory dependency behind abstraction (interface in this example) and perform all the object-to-dependency binding at application’s root.