Comments on: Ditching domain models for reads

By: Bob Jennings

Bob Jennings — Tue, 07 Dec 2010 11:16:42 +0000

@joe,

Waaaah

By: joe

joe — Tue, 07 Dec 2010 04:45:24 +0000

Bob why is it that people feel the need to satisfy their own ego by pointing out that new ways of writing code is only repackaging of old ideas? please inform me?

Of course CQRS is not new but the way it is presented to the masses is new and the more people it reaches the more chance people have of writing better code and not reinventing the wheel.

Don’t slam the architect buzz of the week, slam the original people who ‘were hip to long before’ for not sharing their ideas with the masses back then.

By: Bob Jennings

Bob Jennings — Tue, 07 Dec 2010 00:24:59 +0000

@ “CQRS gets slammed a bit because it’s a named thing”

IMO, CQRS gets slammed because it often smells of over-architecture – yet more and more abstractions that often do more to satisfy the ego of the architect than to do the simplest thing possible in order to solve age old problems.

That being said, the whole separate model for reads is excellent and very practical advice, that often yields immediate results. On the other hand, it’s a technique that I believe many people were hip to long before CQRS became another acronym of the day.

By: Ian Cooper

Ian Cooper — Mon, 06 Dec 2010 22:51:18 +0000

We came to the collection of patterns under the CQRS banner for exactly this reason and are about to replace another legacy controller for just this issue. CQRS gets slammed a bit because it’s a named thing, but underlying it is exactly this sort of guidance to these real world issues. It’s the problem with naming a thing I guess, folks stop seeing the history that created it.

By: Ian Cooper

Ian Cooper — Mon, 06 Dec 2010 22:51:16 +0000

By: Jason Meckley

Jason Meckley — Mon, 06 Dec 2010 17:51:09 +0000

IStatelessSession would also help in these scenarios.

By: Corey

Corey — Mon, 06 Dec 2010 15:55:35 +0000

We have begun to use SQL Views for our screen bound dto’s. Even more scary is that I find some of our command stuff moving to sprocs where appropriate also. Regardless of how you change things one benefit to separating query from command is that the command side becomes much simpler when it isn’t also serving the needs of the UI.

By: Steve Powell

Steve Powell — Mon, 06 Dec 2010 15:24:58 +0000

We are doing more and more of this. It is so hard doing any sort of ‘list’ type pages using a domain model without causing loads of lazy load issues that we now use projection (even via Session.CreateSQLQuery) for almost all of our page renders. The Q in CQS. Mega quick and dirty unit test on each query of course. Seems to be working out quite well atm.

By: Scott White

Scott White — Mon, 06 Dec 2010 15:04:20 +0000

Can’t implicit updates be avoided if you require updates to occur in a transaction block or by using AOP? Not sure that I’ve had NHibernate do this to me before but I used OSIV with Spring.Net and only used a transaction block when I actually intended to change something.