Comparison
Data access objectvsRepository pattern
Data access object
there is one class per table with find, insert, update and delete on it, and the method names match the storage.
An object that encapsulates access to a particular data source, exposing operations shaped by the storage rather than by the domain. It is older, broader and less opinionated than the repository, and in most codebases the two words are used interchangeably — which is fine as long as everyone agrees which of the two things they actually built. The distinction matters when a repository starts returning rows or a DAO starts enforcing invariants.
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 →