I know your question was for Jimmy but the way that we have tackled this on my projects is by using a View Model (UX) or RequestResponse (Web Service) approach which means that each action would return a DTO (View Model or Response). Then you have your query object encapsulate all the querying logic needed to get the data needed by the DTO that is returned from your action method. We actually use stored procedures for this a lot of the time as it’s easier write complex queries for most developers in a SP than using an ORM API. This allows you to maintain a thin controller but still have good code organization. To make things easier use Auto-Mapper to implement the Entity Translation pattern in the Query Object to move data out of your entities an into the DTO.

Simply have your IRepository base interface have a method of GetBySpecification (or if you want, GetByQueryObject). Pass in a Specification – you now have an extensible query capability without littering repository code all over controllers and other objects. In addition like your query objects you have reusable components to create more complex queries.

My question would be this: You mention that you would generally restrict controllers to one query object per controller. Does that mean that your controller would project your domain classes to some kind of DTO that contains the data or do you prefer to return the entities directly?

What if you need to fetch multiple types of data, like blog posts and maybe a list of all blog tags? Would you then have separate controllers for each of these queries with one query object per controller or would you have one controller with a query object that fetches both lists?

Putting it a different way, I don’t fabricate business needs, I work with the business to prove that needs exist. I don’t like speculative architecture.

Remember, we’re trying to match our code to the constraints we’re working under. I don’t have a constraint to have to be able to switch ORMs or database technologies.

However, if that need actually existed, I would provide seams for doing so, and isolate as I see appropriately. So for the context you described, I wholeheartedly agree with you!

That said, to me most Repository pattern implementations I’ve seen are closer to a Transaction Script and in that context I’d probably always prefer Query Object and not even bother providing a Repository pattern alternative. Transaction scripts just end up being a big, confusing, bloated interface on any decent complex project.