We've been discussing specifications as a way of expressing what objects we need to get back from repositories and we found lots of interesting articles:
- In Memory Filtering Of Repository Results - This approach seems to get all the objects then use the specification to filter in memory.
- Linq - There must be loads of other posts on this sort of things but this ones very good.
- .NET Example - I personally have a few issues with this approach, its not high enough in abstraction but I presume you could build quite abstract specifications on top of it.
- DDD Discussion 1 - Mainly focusing on what Linq brings us.
- DDD Discussion 2 - The reality of Query Object v Specification using current technologies, its a mother of a discussion but interesting none the less.
- Ayende - proposes creating ICriteria based queries from the domain. Personally I minimize calls from the domain to the repositories, just to make testing easy. In general though although we use NHibernate our repositories don't expose NHibernate specific features on the interface, partly for simplicity but mainly so if we did need to walk away from NHibernate we'd have some chance of managing to do it.
- Ayende 2 - Doesn't really give much away.
My reading of the whole thing is that specifications are great for validation rules (we use this approach), great for selecting things from in memory collections and great when constructing new objects in factories.
However trying to use a single specification that can evaluate in memory objects and that can spit out the necessary HQL/ICriteria/SQL for use by the repository is not going to be simple. The best I think most people can do is to have a method to evaluate in-memory objects and an HQL or query object to do the equivalent against the DB. Or wait for Linq and see how that all fits in.
Anyway on the more general topic of the specification pattern there are some great links, two of which are: