Ditching domain models for reads

Last week was a tipping point for me.  We had an issue where a production service failed because NHibernate was trying to issue thousands of UPDATE calls for domain objects that we didn’t update.  It turned out that we had added a new column for an entity, but did not fill this column with values for existing objects.  When we loaded up these objects for a bulk export, NHibernate detected changes for these thousands of objects.

Needless to say, trying to issue thousands of UPDATE calls in a single transaction is a fantastic way to bring down the entire system.

NHibernate wasn’t doing anything wrong here.  It was just the feature of automatic dirty checking doing its job.  However, unless I actually change something, I don’t really want to have anything updated.

In this case, the fix was to use the projection features of NHibernate to project into a DTO, so that a persistent, tracked entity never enters into the mix.  There are exceptions to this rule, as some entities like configuration or persistent metadata are just plain CRUD objects.

But unless I intend to change an entity by processing a command, it seems to make more and more sense to separate the read and write concerns architecturally through techniques like projection, bypassing the need to load up an entity if I’m not actually intending to change it.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Domain-Driven Design, NHibernate. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • https://scottwhite.blogspot.com Scott White

    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.

  • http://datalogicsolutions.blogspot.com/ Steve Powell

    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.

  • Corey

    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.

  • Jason Meckley

    IStatelessSession would also help in these scenarios.

  • Ian Cooper

    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.

  • Ian Cooper

    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.

  • Bob Jennings

    @ “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.

  • joe

    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.

  • Bob Jennings

    @joe,

    Waaaah