title: Specification pattern and DDD
body: <p>Within the context of a personal play project for learning more about DDD patterns, I am missing a <a href="http://en.wikipedia.org/wiki/Specification_pattern" rel="nofollow">Specification</a> object for my filters. </p>
  
  <p>Looking around for examples, it seems that everything (like LinQ) is oriented towards SQL databases. However with many NoSQL databases most queries, even just a "select * from table" requires a predefined view. Nevertheless, if the repository is mapping a web service even the type of queries is much more rigid.</p>
  
  <p>Are there variations of the Specification pattern taking into account the limitations of non SQL databases? I have the feeling that this would require the use of inheritance and static declarations to support different type of persistence backends.</p>
  
  <p>How should I combine "sorting" and "filtering" in my repositories? As an example consider the repository for a list of <strong>Order</strong> items.</p>
  
  <pre><code>(Query)findAllSortedByDate;
  (Query)findAllSortedByName;
  (Query)findAllSortedByQuantity;
  </code></pre>
  
  <p>So these are different type of sorting when displayed by a table. Since I might handle large results, I never considered sorting or filtering in my views or view models. Initially I thought about a <strong>Proyection</strong> class that selects the right query from a repository according the user actions. However this does not work well if I want to combine different sort strategies along different filters.</p>
  
  <p>Obviously I need some type of "specification" object, but I am not sure if:</p>
  
  <ol>
  <li>Should I use them for my <em>repositories</em>, making them smarter? Or should I use them for my <em>view models</em>?</li>
  <li>How can properly restrict my specification objects for a good polyglot persistence?</li>
  </ol>
  
  <p>Originally I thought about performing any query with a <strong>Repository</strong> acting as a <a href="http://martinfowler.com/eaaCatalog/repository.html" rel="nofollow">collection-like interface</a> but now I am noticing that a <strong>view model</strong> may also behave as "stateful" collection-like interface while the former are "stateless" collection-like interfaces.</p>
  
  <ol>
  <li>Overall should I try to keep any type of sorting/filtering inside my repositories? It seems that doing so, might add unnecessary complexity if all the query results can be loaded into memory.</li>
  </ol>
  
  <p><strong>UPDATE</strong>:
  To spice up this question, consider also that although NoSQL views can be filtered and sorted, a full text search might need an external indexing engine such as Lucene or SQLite-FTS providing only the unique identity of the Entities for a query that must be sorted and filtered again.</p>