Transactions in the Repository Pattern

Solution 1:

Booting my computer this morning I faced the exact problem for a project I am working on. I had some ideas which lead to the following design - and comments would be more than awesome. Unfortunately the design suggested by Josh isn't possible, as I have to work with a remote SQL server and can't enable the Distribute Transaction Coordinator service it relies on.

My solution is based on a few yet simple changes to my existing code.

First, I have all my repositories implement a simple marker interface:

/// <summary>
/// A base interface for all repositories to implement.
/// </summary>
public interface IRepository
{ }

Secondly, I let all my transaction enabled repositories implement the following interface:

/// <summary>
/// Provides methods to enable transaction support.
/// </summary>
public interface IHasTransactions : IRepository
{
    /// <summary>
    /// Initiates a transaction scope.
    /// </summary>
    void BeginTransaction();

    /// <summary>
    /// Executes the transaction.
    /// </summary>
    void CommitTransaction();
}

The idea is that in all my repositories I implement this interface and add code which introduces transaction directly depending on the actual provider (for fake repositories I have made a list of delegates which gets executed on commit). For LINQ to SQL it would be easy to make implementations such as:

#region IHasTransactions Members

public void BeginTransaction()
{
    _db.Transaction = _db.Connection.BeginTransaction();
}

public void CommitTransaction()
{
    _db.Transaction.Commit();
}

#endregion

This of course requires that a new repository class is created for each thread, but this is reasonable for my project.

Each method using the repository needs to invoke the BeginTransaction() and the EndTransaction(), if the repository implements IHasTransactions. To make this call even easier, I came up with the following extensions:

/// <summary>
/// Extensions for spawning and subsequently executing a transaction.
/// </summary>
public static class TransactionExtensions
{
    /// <summary>
    /// Begins a transaction if the repository implements <see cref="IHasTransactions"/>.
    /// </summary>
    /// <param name="repository"></param>
    public static void BeginTransaction(this IRepository repository)
    {
        var transactionSupport = repository as IHasTransactions;
        if (transactionSupport != null)
        {
            transactionSupport.BeginTransaction();
        }
    }

    public static void CommitTransaction(this IRepository repository)
    {
        var transactionSupport = repository as IHasTransactions;
        if (transactionSupport != null)
        {
            transactionSupport.CommitTransaction();
        }
    }
}

Comments are appreciated!

Solution 2:

I would look at using some type of Transaction Scope / Context system. So you might have the following code which is roughly based on .Net & C#.

public class OrderService
{

public void CreateNewOrder(Order order, Customer customer)
{
  //Set up our transactional boundary.
  using (TransactionScope ts=new TransactionScope())
  {
    IOrderRepository orderRepos=GetOrderRespository();
    orderRepos.SaveNew(order);
    customer.Status=CustomerStatus.OrderPlaced;

    ICustomerRepository customerRepository=GetCustomerRepository();
    customerRepository.Save(customer)
    ts.Commit();   
   }
}
}

TransactionScope can nest so let's say you had an action which crossed multiple services your application would create a TransactionScope as well. Now in the current .net if you use the TransactionScope they have you risk escallating to a DTC but this will be resolved in the future.

We had created our own TransactionScope class which basically managed our DB connections and used local SQL transactions.

Solution 3:

How do I encapsulate the saving of more than one entity in a transactional manner using the repository pattern? For example, what if I wanted to add an order and update the customer status based on that order creation, but only do so if the order completed successfully? Keep in mind that for this example, orders are not a collection inside the customer. They are their own entity.

Its not a responsibility of the repository, its usually something done at a higher level. Although you said your not interested in specific technologies I think its worth tying down the solutions, for example when using NHibernate with a Web app you'd probably consider using session-per request.

So if you can manage transactions at a higher level then my two options would be:

1. Upfront check - For example in a service co-ordinating the behavior decide if you want to proceed by asking the Order/Customer, if either say they don't then don't even try to update either of them.
2. Rollback - Just proceed updating the Customer/Order and if things fail part way through rollback the database transaction.

If you go for the second option then the question is what happens to the in-memory objects, your Customer might be left in an inconsistent state. If that matters, and I work in scenarios where it doesn't as the object was only loaded in for that request, then I'd be considering the upfront check if its possible because its a lot easier than the alternatives (rolling back the in-memory changes or reloading the objects).