Vinay's Blog

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.

Lets get started by creating our domain objects.

The domain objects

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

And for the application itself…

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.

In my pervious posts, I wrote about the aspects of TDD and DDD a bit, and following up on the series, I will start building the sample application from this post onwards. For the lack of better name, I will be calling the application DDDBlog.

Setting up the project

Lets create the project structure as shown below.

This post was supposed to be about the layering in my sample project, but I thought I would talk a bit about TDD as its new to me. This is by no means an exhaustive post on TDD

Test Driven Development

TDD could be told as an approach in development, where we are writing tests to know the area for which we are building the software. Tests written during the development phase helps you in understanding the domain, and, after development tests helps us document that system. Following are a few things about TDD that I have understood

The Steps

1) We write a failing test. We have to identity whether the test is testing what is intended in this step.
2) We make sure the test written in step 1 passes.
3) We refactor the code written in step 2.

This is a continuation post. You can read the first part here.

Aggregates and Aggregate Root

In a software there can invariably be many objects, and some of these objects are bound to be related to each other in some way. These objects that are related to each other are known as aggregates and an aggregate root is the object that holds them together. Aggregate root is always an entity. Say for example in a blog application a comment would be related to a post. So post and comments become an aggregate and post becomes the aggregate root as there cant be any comments without a post.

Aggregates are to be considered as one unit with regard to any data manipulation and these aggregates can be accessed from outside only through their aggregate root. This mechanism of accessing the objects only by the root helps in maintain data integrity as individual objects can not be changed directly.

What is DDD?

DDD could be called as a methodology or a set of patterns which help us in developing a software pertaining to the domain. Here what domain means, is the actual system for which we are building the software. DDD is not breaking away from the core Object Oriented design principles, but to utilize them in the right way. There are many aspects in DDD which we need to consider when building an application. Following are the aspects and their brief explanations from what I have understood.

The Ubiquitous Language ( UL )

Developers when building a software tend to wholly dwell into the technical aspects of the the application unlike the domain experts who have an extensive knowledge of the problem domain rather than the technical solution for it. When a domain expert is sharing his expertise, he will using a lot of terms that may not be understood by the development team, thus brining in a communication gap between the two. 

If you are closely following the things that are happening around the .NET development arena, there is a lot of interest in DDD ( Domain Driven Design ) along with other TLA’s like TDD ( Test Driven Development), MVC ( Model-View-Controller ) etc. It was hard for me not to notice the buzz around DDD and got me interested in it. As the title says, I would want to see what these things mean and how to develop an application around or rather using these technologies.