MVC 3, where to commit unit of work?

Question

I've just finished setting up a project using MVC 3, Fluent nHibernate, AutoMapper, and Autofac, making use of generic repositories, the unit of work pattern, and a 3-tiered design. I now have come to this problem:

I have a unit of work, but I do not know where/how to commit it. Starting it is easier; use Autofac, inject on a per-HTTP request basis - the constructor for my unit of work begins the transaction. However, what I realized was I ended up with business classes like this:

private readonly IUnitOfWork _unitOfWork;
private readonly IUserRepository _userRepository;

public UserHandler(
    IUserRepository userRepository, 
    IUnitOfWork unitOfWork)
{
    _userRepository = userRepository;
    _unitOfWork = unitOfWork;
}

public void CreateUser(User user)
{
    // Fill the date fields
    user.CreationDt = DateTime.Now;
    user.ModifiedDt = DateTime.Now;

    // Add the user 
    _userRepository.Add(user);

    // Commit the changes
    _unitOfWork.Commit();
}

This is great, as long as I don't need to do any other transactions. But what if, after calling .Add, I decide to call another business class with a similar method? Then I've got 2 commits, which I'm assuming will blow up since I will be attempting to end an already completed transaction.

I thought about putting the commit in my UnitOfWork's Dispose, but that is bad news if an exception occurs. I have seen some cases where people also inject their UnitOfWork into their controllers, but this seems wrong as it breaks separation of concerns, with your controllers bypassing the business layer and calling a database layer directly. Lastly, I'm currently looking into using an attribute like the one used in Sharp Architecture, but I'm also unsure if this is proper approach (again, aren't you giving the controller direct access/knowledge of the data layer?).

Can someone share some wisdom as to where I should be committing?

score 2 · Answer 1 · answered Jun 25 '12 at 19:35

2

As far as you share your database connection within one request you can Begin transaction and commit once response is sent to the client. I head a special action filter to achieve this.

public sealed class CommitOnSuccess : ActionFilterAttribute
{
    public IUnitOfWork UnitOfWork { get; set; }

    public override void OnActionExecuted(ActionExecutedContext filterContext)
    {
        if (filterContext.Exception == null)
            UnitOfWork.Commit();
    }
}

That's how I made my action methods plain and lightweight

[CommitOnSuccess]
[HttpPost]
public ActionResult Create(ApplicationManagementViewModel model)
{

}

and changes are to be performed on entities obtained from the repository within Create method

answered Jun 25 '12 at 19:35

amdmax

771
3
14

Doesn't this violate separation of concerns? Assuming you're working with some sort of tiered application, you've now got your presentation layer monkeying around directly with your persistence layer by calling the unit of work. You also have to apply this to every action which seems tedious (compared to Baz1ngas approach). – intrepidus Jun 27 '12 at 17:05
As far as repository is used as a simple collection (I only add, update, remove items from it) and action filters are basically attributes of methods I would claim that it's ok. And it's pretty much aspects / attributes of a method. And there is a guarantee that you transaction will not committed if it doesn't have to be. – amdmax Jun 28 '12 at 16:21

Baz1nga · Accepted Answer · 2012-06-25T19:42:02.640

0

in application end request you can commit your unit of work. In your global.asax.cs file add the following function :

protected void Application_EndRequest(object sender, EventArgs e)
    {
     //code to commit unit of work
    }

Also since you are using Autofac you could as well scope IUnitOfWork to InstancePerLifetimeScope and make the class implement IDisposable and in your Dispose function you can commit your session. How is it an issue when an exception occurs, you could have a check in your code something like this:

 if ( HttpContext.Current != null && HttpContext.Current.Error != null) 
      transaction.Rollback();
 else
      transaction.Commit();

edited Jun 25 '12 at 19:42

answered Jun 25 '12 at 19:18

Baz1nga

15,485
3
35
61

1

@heyseuss is correct - commit in `Dispose` is not a good idea. – default.kramer Jun 25 '12 at 19:35
Specifically, if an exception is thrown, `Dispose` will still be called, meaning you risk committing invalid data. Generally, `Dispose` should only be used for cleanup, see [this question](http://stackoverflow.com/q/538060/644812) – default.kramer Jun 26 '12 at 15:28
Hmm, I see that now... it looks okay I guess. I wouldn't do it myself but I also wouldn't be opposed if someone really wanted to do it. – default.kramer Jun 26 '12 at 16:47
So with the guard in place, is there any functional reason not to do this? This seems far simpler and more elegant than sticking a decorator on every action that needs it. – intrepidus Jun 27 '12 at 17:03
I dont see why not.. We have been doing this in production for 2 years without any issues.. and yea I am not a big fan of the decorator pattern either but you can still stick the attribute on the controller itself right or all your cotrollers derive from a common base controller that extends Controller and you stick your attribute on this common base controller – Baz1nga Jun 27 '12 at 17:51
True enough, but I still dislike the idea of my MVC app calling my persistence layer 2 levels down...so I'll stick with your solution. Thank you much! – intrepidus Jun 27 '12 at 20:06

MVC 3, where to commit unit of work?

2 Answers2