Before we get into the CQRS implementation, lets take a comparative look at using the ‘built-in’ ORM tool in the .Net framework – the Entity Framework (EF).  Unlike NHibernate, you do NOT need to go digging across the internet (or load some NuGet packages) to get EF running.

Microsoft has really done their homework with the tooling surrounding EF.  In NHibernate, we needed to hand-code a series of XML mapping and configuration files that get compiled into our DLL and EXE files.  In contrast, with EF a developer can point the data modelling wizard at a database and all of the corresponding classes and goo to connect the database to your DLL is just generated.

That’s what I did… I added a new “ADO.Net Entity Data Model”, chose to generate from database and got this popup:

.. and the resultant model looks like:

That was a bit too easy…  to get our Product and Evaluation objects to re-map into our predefined interfaces, we need to write some partial classes. Easy:

Wow…way too easy…  last task, connect up the repository model as defined by our IRepository interface.  Here’s the GetById implementation:

The rest of the source code is available at:  https://github.com/csharpfritz/Fritz.Evaluations

So, let’s crank up NDepend and extract some metrics:

88 lines of code in 7 types.  Our most complex method has a complexity of 3, ProductRepository.Save.  I blame this on my naive approach to adding a Product to the entity context and triggering the SaveChanges method on the context.

In less than an hour, I had my entire data access layer generated and wired up with Entity Framework.  The tooling generated some code that is very manageable and for smaller projects, I can live with that.  In comparison to NHibernate, if I need more control and want to reduce the complexity of my code, I’ll use NHibernate.  However, if I have a simple project that needs a quick data access layer, I’m using Entity Framework.

Next up in the series:  our initial discussion of CQRS.  This is NOT a simple topic, and will be spread over several posts.  The first of these posts will describe the design approach and we’ll cover the ‘simplest implementation’ according to Greg Young.  We’ll get into Event Storage in the second post, and we’ll finally hit some testing approaches in the third post.

I’ve been tip-toeing around this topic, but I think it should be addressed now.  How are we going to access this architecture from our website?  What work is Asp.Net doing in this thing?

First off:  I am faithfully drinking the Asp.Net MVC kool-aid.  This is some great stuff, and I intend to use that web application model for this example.  I believe that MVC Views should be stupid – check that, MVC projects should be SIMPLE.  These web projects should have little to no logic, as the only purpose of this project is to emit HTML and other angle-bracket code.

Thanks to NuGet, I can easily sprinkle in the Unity IoC Container and MVC3 bindings for it.  To complete the Unity installation, I added a configuration section to web.config:

I also updated the BootStrapper class to configure the UnityContainer at application startup:

Next, I’m going to add a ProductController with a constructor that accepts an IProductRepository.  At this point, I can now swap the data access architectures in and out with a simple change in web.config.

My Index action looks very simple:

and finally, a simple index.cshtml to generate a table that outputs the details of our Products.  Piece of cake…  We can get fancy with our views later, and since this series isn’t about fancy web pages, I’ll end this post about UI here.

I’ll wire up the remaining actions and UI for the web over the next day or two, and you will find the results on the GitHub repository with one of the next posts in the series.

Its now time to start with our first entrant into the ORM throwdown: NHibernate.  I’ll spare you the nonsense about what NHibernate is and why you should use it.  For now, I’ll just point you to nhforge.org for more information about the tool.

As a good practice, I prefer to isolate my NHibernate implementation of the data access layer in a class library project.  This implementation allows me to upgrade and tune the data access layer without directly modifying the rest of the application.  Others will argue that by doing this, I have lost the ability to control the boundaries of a unit of work in the context of a web session.  While I agree, I have given up that control, I prefer to have the isolation of my data access code.

First thing to build is a ProductRepository that will access the database.  To do this, with NHibernate, we need an XML configuration file that will define the dialect NHibernate will generate and utilize when communicating with our data store.  My hibernate.cfg.xml file looks like this:

We next need to build an object that will facilitate the presentation of NHibernate sessions.  The NHibernate session is our gateway to the database.  The catch here is, the session factory initialization is a performance drain.  To combat this, I have created a simple (read: not optimized) wrapper to provide static access to the factory:

A quick note:  see line 30..  I have written a TextWriter that will output to the immediate window in VisualStudio every sql statement that NHibernate compiles.  Yeah, I’m tricky like that  😉

I have written a class, therefore its time to write a test:

I have placed my sql connection string in a constant in this class, hidden in the Fields region, and marked the test as ‘Ignore’.  Why?  I don’t want to run this very time-consuming unit test every time I run my suite, this is more a verification that we are configured properly.

Next steps are to create concrete IEvaluation and IProduct objects, and create a ProductRepository.  I won’t bore you with the concrete object definitions and mapping files here, but the repository to use these objects looks something like:

NDepend reports the following on our NHibernate project:

56 lines of C# code across 5 classes.  The most complex method (SessionFactory.Init) has a cyclomatic complexity of 3.  All other methods have a complexity of 1.  This is good…  it means the code is not complex.  

However, there is a distinct code smell, as direct references to the database structure are now embedded in my DLL.  Additionally, all of these references are buried in object mapping hbm.xml files that are embedded resources in the DLL… This library is NOT very resistant to changes in the database without modifications and recompiling.

Source code is now available at:  https://github.com/csharpfritz/Fritz.Evaluations

In our next post we’ll look at Microsoft’s offering in the ORM game – THE Entity Framework.

Next up… the MsSql 2008 database structure.  If we’re building a typical n-tier application with ORM, we need the “R” – the Relational Database in this mix.  This is in preparation for the construction of an NHibernate data access layer (DAL).  If you are like me, when it comes to building an application, the first thing you design out is what and how we’re going to store these objects.

First up, define the Product table:

I’m a stickler for sql scripts to be idempotent, as this format allows me to re-run the script as many times as my paranoid mind thinks I need to.  I also prefer to format sql by adding PRINT statements to report to me or my support personnel exactly what the script performed.

The corresponding Evaluation table looks like this:

At this point, we are 29 lines of OUR code into storing our data.  We can stop here in our database, as our ORM tools have facilities to generate appropriate commands to select, insert, update, and delete data from these tables.

In our next post, I’ll document the creation of a simple NHibernate repository using an existing Sql 2008 Express database.  We’ll cut some c-sharp, some hbm.xml files, and maybe just maybe a unit test or two.