Setting up StructureMap and The Unit Of Work ActionFilter

UnitOfWork ActionFilter

In my previous post I had created the repository implementations along with unit of work. But how do we use this unit of work in our application. ASP.NET MVC has a concept of ActionFilters. These could be applied to an action or a controller in general. The two main methods that concern us are OnActionExecuting and the OnActionExecuted. As seen in the code below we call the initialize method of the unit of work which would create a new transaction for us and this is held until the action is complete after which we commit the transaction. We are getting a new instance of _unitOfWork through an IoC container which I will talk about in a bit.

NHibernate Repository and Unit Of Work

In my previous post we looked at the domain model and the class maps associated with it. In this post lets look at the Repository and Unit Of Work implementations.

Note: The following is based on the FubuMVC contrib project.

IRepository

A repository is an abstraction layer which gives your application an in memory domain object collection. This layer helps in making you application agnostic about where the data is coming from or where it is persisted into. It could well be a flat file or any other RDBMS. Preferably each of your domain object would have its own repository. But for the sake of keeping it simple, I am using a generic repository in the following code.

Mapping The Classes And Session Source Configuration

As mentioned in my previous post, this series will no longer be a talk about DDD as a blog app is too trivial to show ( learn ) the power of it. I will be using some of the patterns of DDD though. So I have changed the name of the app I am building. It will be called MyPersonalBlog ( MPBlog ) henceforth.

The project structure has changed a bit from what I had shown here. There is no longer separate layers for infrastructure and domain. I have clubbed these 2 layers into a single Core layer. The other layers are just the same.

I got a (few) comment by Colin on my previous post on the series that I had started.

He goes like this for me saying that I am the domain expert for the sample application I was building.

My main feedback would be that a DDD example done without an external domain expert probably isn’t a good idea. A few of us have tried this over the years and decided it wasn’t a great idea, I’d at the least indicate your using *some* of the patterns from DDD but not others (including the working with domain experts) and that this isn’t necessarily the sort of problem that suits a full DDD approach

In my previous post, we looked at setting up the project structure and the tools and libraries that we’ll need to build the application. In this post we’ll look at creating a few base classes.

Layer SuperType: The Entity Base Class

Before we start of creating the domain objects, lets first create the base entity object. As discussed before, an entity is something that has an identity. This would be our layer supertype because this class will be inherited by all our domain objects that needs to have an identity.