And I agree with Udi and Ayende (and even Greg). If you can access the data store using NHibernate or LINQ2SQL, then by all means do that. It’s an explicit dependency on a system that is designed for query performance. Introducing 2+ message delays into the query path adds no real value in this situation.

As for the obese IDataAccessor (or whatever) with 50 methods on it, you can still break your collection of queries into individual classes, with each class designed to handle the specifics of the query (instead of a bunch of overloaded arguments on a method-heavy class). It allows allows you to separate out the queries and make them more testable given a known set of data being queried (with can be unit tested with something like SQLite copying a preloaded database to ensure consistent results for unit tests).

It also makes it easy to apply a data caching layer around the query objects, allowing each query to control aspects such as cache lifetime for query results, batching of results independent of the actual number of rows requested, etc.

The next post will also address a more complex query scenario that uses messaging, but this series is about building a SERVICE gateway, not a data gateway. In the case of these queries, a remote service is being queried for the data (think SAP, etc.) and not a set of tables in a SQL database.

Typically messages are used for asynchronous communication. When you’re performing a query, there are much better tools for the job. Why not just talk directly to the database? Databases are very good at querying data. You could abstract the database using Linq2Sql or NHibernate Projections or something similar. In this way, you are able to get all of the data for a particular screen back in one call without regards to any type of domain or object model.

Then, when you want to mutate the data in some fashion, send a message asynchronously to your domain model (or whatever mechanism you use to dictate business logic). The domain model would update the database and you’re good to go.

Greg Young talks a lot about this pattern—it’s called Command Query Responsibility Separation (CQRS). I’ve written up a little bit about how to get started going down that road:
http://jonathan-oliver.blogspot.com/2009/03/dddd-and-cqs-getting-started.html

One question though. Both Ayende and Udi are “screaming”:
“Don’t use messaging for quering data”.

Personally I’m still straggling to understand why not, since
“promoting” the query to a message, would yield me (among other things) the benefit that the client (ex. the Controller in an MVC application) has no dependency on another class or interface (just the service bus) and is completely unaware of who gives back the data and with what mechanism, plus it would mean only one Message Handler for each query/message instead of some bloated class/facade with 50 methods “GetOrderByStatus(…)”, “GetOrderByCriteria(…)”, “GetOrdersOfCustomer(…), etc…

Any comment on that?