title: Repository and query objects pattern. How to implement complex queries
body: <p>I have read a lot of posts of the repository pattern but there are a few practical problems that they doesn't seem to solve or explain. This is what I understand about this two patterns:</p>
  <p><strong>The repository and the query pattern are complementary:</strong> Query objects represents business logic (WHERE clauses) and the repository pattern has a Get(IPredicate) method that takes a query object and returns a SELECT WHERE  result</p>
  <p><strong>The repository should not have business logic:</strong> All the business logic must go on the query objects</p>
  <p>Currently I have a class that wraps each logical object (which almost always is a single entity object) that implements multiple &quot;Get&quot; methods that implement most complex queries (joins, groupBy, etc...), this isn't a good pattern because classes tend to grow a lot because of boilerplate code for similar queries and its public methods are dependent on context that this class will be used,  thus, making this classes unusable for multiple projects that depends on the same database, which is my primary goal for this project refactoring.</p>
  <p><strong>How queries that are more complex than a single SELECT WHERE are implemented with this two patterns without leaking business logic into the repository?</strong></p>
  <p>Or if this business logic doesn't fit into the repository nor the query objects
  <em>where does this logic fit?</em></p>