I’ve been interested in CQRS – Command Query Responsibility Segregation for sometime now and been very fond of the simple command pattern for a long while. The command pattern is baked into new technologies such as WPF (Microsoft’s Windows Presentation Foundation). I wrote a post a while back on how to implement the nice clean command pattern here: http://www.simonrhart.com/2010/03/making-use-of-command-pattern-on.html

My post assumes you are familiar with patterns such as dependency injection and IoC containers as these are additional concepts promote good use of the command pattern and in turn CQRS.

If you’re aware of the command pattern or have read my post linked above, you’ll see how nice it is in that it promotes the “Single Responsibility Principle” in that an object should only have 1 reason to change. In other words, do not over-complicate your code. This not only makes your code easier to read, it makes it easier to test and maintain and easier to apply rules such as FxCop during build processes to.

CQRS is an architectural design pattern that extends the command pattern. Udi Dahan has a great post on what CQRS is designed to solve here: http://www.udidahan.com/2009/12/09/clarified-cqrs/

With the traditional command pattern, everything gets executed. So your queries and updates might execute within one command. So you quite possibly execute a repository layer that gets some data from a data store (perhaps via an ORM), then you might create a unit of work, make changes then write them back to the data store. Although this is testable as your command isn’t doing too much, it could be better to separate the two. Why would you do that? well it gives you the opportunity to have a cache store for queries. So when a create, update or delete command is executed, the command updates a separate cache by simply serializing the data perhaps as JSON to a distributed cache – something like Windows Server AppFabric Velocity for quick retrieval of query commands later by serializing back into the domain or DTO object. So in this case, when a query comes in, instead of it going through all those layers to get data from a database/data store it first looks in the distributed cache. If found, then serializes the data into the domain object or data transfer object and returns to the caller. This is lightning fast.

What I explained above is in contrast to a typical system, your retrieval commands would receive a request in the form of a context, this would then possibly call a repository layer, that then might call into an ORM that serves up a domain object of the thing you’re looking for. There is a lot of layers here just for displaying data. This is where CQRS can simplify this.

You should be able to see from this that CQRS is designed to simplify the whole process of writes vs reads. As I said the reads could be some sort of distributed caching technology like Velocity or memcached.

I attended the CWDNUG (Canary Wharf Dot Net User Group) meeting on Wednesday 1st June (last night): http://www.meetup.com/cwdnug/events/18182511/ although execution of the presentation could have been better the content was ok. The presentaion talked about Event Sourcing too which I think is another post as this can be used with CQRS in certain senarios.

For me I think CQRS for separating out queries from commands (writes, creation and updates) and keeping the data store as a RDBMS normal form is a good place to be. Event Sourcing – which I will talk about later is good for green field projects.