ORM vs. CQRS/ES throwdown – Part 1 – Introduction

Leave a reply

For almost 18 months now, I’ve been reading and reviewing the CQRS architectural approach.  I’ve been using a typical “n-tier” ORM-like approach to structuring my web applications since I started programming in this space more than 10 years ago.

Typical n-tier architecture

I met Udi Dahan in the Spring of 2009 at a Philly.Net code camp.  I was speaking on Asp.Net MVC, and he was presenting on some CQRS basics.  At this time, I had no idea what CQRS was, and was focused on my MVC / NHibernate world. Chatting in the speaker’s lounge, he got me more focused on the simple problem of web programming with Asp.Net – we’re only generating strings.  

If all that Asp.Net programming is, all of this event handling, ViewState management, GET/POST processing, Session storage, and application management boils down to strings… it sure seems like an over-complicated problem.  It got me starting to think about simplifying the string-generation problem.

I went to Tech Ed that year, and after listening to Jeffrey Palermo, started to consider the idea of an ‘edge database’.  Why not?  It’s easy enough to spin up a Sql Express instance on a web server… so just set one up and replicate common data on it.  The memory and processor overhead of that Sql instance proved a bit too much in my practice and I scrapped the idea.

Fast forward a bit, and we’re presented with some of the goodies in the new Entity Framework.  We can generate our objects from the database!  Or we can start in code and generate our database!  All of the plumbing and hbm.xml files from my NHibernate days were beginning to melt away.  After listening to some podcasts with Julie Lerman and Scott Hanselman, I was convinced that the simplification I was looking for was Entity Framework coupled with some neat T4 scripts to generate and manage my MVC3 views.

About 4 months ago, I was offered an opportunity to hear Steve Bohlen talk on DDD and CQRS approaches at a Philly Alt.Net meeting.  At this point, CQRS suddenly made sense for me.  The simplification of smaller objects, easier to manage database layers (in some cases no database layer!) and the intrigue of using NoSQL options to store my front end cache was too good to overlook.

CQRS Architecture

That same group invited Greg Young to speak in August.  After reading through some of his examples, and watching his lectures online, I knew I had to see and hear his talk in person.  I was not disappointed… all of my questions about CQRS were answered and I was confident in my ability to define and work within this architecture’s guidelines.

And that brings me to this:  How does CQRS stack up against my tried and true approach of NHibernate / Entity Framework?  I’ve started coding a prototype application that will compare the two approaches and I’ll share those findings in the next few blog posts.

I am going to measure:

  • Relative lines of code on top of the framework
  • Complexity (from nDepend)
  • Testability
  • Maintainability – we’ll change the domain object and see how it affects the rest of the application

This is going to be very interesting.  I hope you find it interesting as well.