WCSF, Repositories and Unit of Work?

This post is part of a series:
- Generic factory and repositories: Part 2 revisited
- Generic factory and repositories: Part 2
- Generic factory and repositories: Part 1
- WCSF, Repositories and Unit of Work?

In my research for designing and implementing modular web applications, I’ve come across the Web Client Software Factory. I’ve already briefly touched this subject in a previous post. It heavily uses the Composite Web Application Block to implement a Model-View-Presenter approach for a web application. It allows developers to compose applications from different pieces  of software (modules). One of the advantages of this approach is that these modules can be developed independently from each other by different teams of developers. Another advantage is that the entire web application consists of separate blocks of software that are loosely coupled. I’m sure you’ve heard that term used by someone before!

As I was evaluating WCSF I stumbled on an interesting question. A question which I have no answer to yet.

In the past I’ve successfully used Microsoft’s Entity Framework. It’s relatively straight forward to implement a Repository Pattern in combination with a Unit of Work. If you have no idea what I’m talking about, here is a nice example. Admittedly, it’s an implementation for NHibernate, but it can just as easily be implemented for EF. The beauty of this approach was that I could use a single ObjectContext and pass it on to multiple repositories. This allowed me to use different repository classes in the same TransactionScope.

Here’s a quick example to show what I mean:

using (TransactionScope ts = new TransactionScope())
{
    // Create unit of work.
    using (IUnitOfWork uof = new ConcreteUnitOfWork())
    {
        // Create repositories and pass unit of work.
        OrderRepository or = new OrderRepository(uof);
        CustomerRepository cr = new CustomerRepository(uof);

        // place order in the system.
        or.Insert(customer.Order);

        // update order history for the customer.
        cr.UpdateHistory(customer);

        // So far, so good! Save all the changes.
        uof.Commit();
        ts.Complete();
    }
}

This is a simple piece of code that shows a single transaction over multiple repositories. In this scenario I had complete control over creating an ObjectContext and releasing its resources (IUnitOfWork implements IDisposable which will clean up any resources). In this way I had full control over creating a fresh ObjectContext for each new business transaction and automatically disposing it when the code finishes executing the using-statement.

I wanted to have the same functionality with implementing WCSF. I’ve had a good long look at the sample OrderManagementRI implementation that comes with the WCSF sources. It’s an excellent example of how they implement repositories and use them as a service within a module. I’ve been able to recreate a similar scenario in my proof of concept application, but I found I no longer have any control on my IUnitOfWork since it is created and passed on to the repositories by using Dependency Injection.

I’ve been searching on the web for a solution, but so far I’ve not found it yet. I’d like to have the same functionality with my IUnitOfWork. I want to be able to create a new one to pass along to multiple repositories in a transaction, while still having the benefits of the modular service approach of WCSF. I have a feeling that I should be able to create something much more to my liking if only I understood more of both WCSF and Dependency Injection principles.

To be continued (again)…

• «Previous Post
• Next Post »