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.