title: Well designed query commands and/or specifications
body: <p>I've been searching for quite some time for a good solution to the problems presented by the typical Repository pattern (growing list of methods for specialized queries, etc.. see: <a href="http://ayende.com/blog/3955/repository-is-the-new-singleton">http://ayende.com/blog/3955/repository-is-the-new-singleton</a>).</p>
  
  <p>I really like the idea of using Command queries, particularly through use of the Specification pattern.  However, my problem with specification is that it only relates to the criteria of simple selections (basically, the where clause), and does not deal with the other issues of queries, such as joining, grouping, subset selection or projection, etc.. basically, all the extra hoops many queries must go through to get the correct set of data. </p>
  
  <p>(note: I use the term "command" as in the Command pattern, also known as query objects.  I'm not talking about command as in command/query separation where there is a distinction made between queries and commands (update, delete, insert))</p>
  
  <p>So I'm looking for alternatives that encapsulate the entire query, but still flexible enough that you're not just swapping spaghetti Repositories for an explosion of command classes.</p>
  
  <p>I've used, for instance Linqspecs, and while I find some value in being able to assign meaningful names to selection criteria, it's just not enough.  Perhaps i'm seeking a blended solution that combines multiple approaches.</p>
  
  <p>I am looking for solutions that others may have developed to either address this problem, or address a different problem but still satisfies these requirements.  In the linked article, Ayende suggests using the nHibernate context directly, but I feel that largely complicates your business layer because it now also has to contain query information.</p>
  
  <p>I'll be offering a bounty on this, as soon as the waiting period elapses.  So please make your solutions bounty worthy, with good explanations and I will select the best solution, and upvote the runners up.</p>
  
  <p>NOTE: I'm looking for something that is ORM based.  Doesn't have to be EF or nHibernate explicitly, but those are the most common and would fit the best.  If it can be easily adapted to other ORM's that would be a bonus.  Linq compatible would also be nice.</p>
  
  <p>UPDATE:  I'm really surprised that there aren't many good suggestions here.  It seems like people are either totally CQRS, or they're completely in the Repository camp.  Most of my apps are not complex enough to warrant CQRS (something with most CQRS advocates readily say that you should not use it for).  </p>
  
  <p>UPDATE:  There seems to be a little confusion here.  I'm not looking for a new data access technology, but rather a reasonably well designed interface between business and data.</p>
  
  <p>Ideally, what i'm looking for is some kind of cross between Query objects, Specification pattern, and repository.  As I said above, Specification pattern only deals with the where clause aspect, and not the other aspects of the query, such as joins, sub-selects, etc..  Repositories deal with the whole query, but get out of hand after a while.  Query objects also deal with the whole query, but I don't want to simply replace repositories with explosions of query objects.</p>