Comparison
Query objectvsRepository pattern
Query object
the filter was built up as an object and handed to the repository, instead of being ten optional parameters.
Representing a query as an object that can be composed, passed around and translated into SQL at the edge. It keeps a repository from growing forty finder methods, one per combination of filters the UI has ever needed. The specification pattern is a domain-flavoured version of the same idea, with the extra requirement that the criteria are also checkable against an object in memory.
Full entry →Repository pattern
the code asks for the customer as if from an in-memory collection, and where it actually came from is somewhere else.
An abstraction that presents stored aggregates as though they were a collection, so domain code queries objects rather than rows. It is a domain-driven design idea: one repository per aggregate root, with methods named in the language of the domain, not one per table. That is the real difference from a DAO — a repository is defined by the model it serves, a DAO by the storage it wraps — and it is lost the moment a repository grows a method per query the UI happens to need.
Full entry →