Tue Dec 2, 2003 12:04 pm
What is the difference between DAO and repository?
DaveFord
Isn't there one DAO for each domain object yet only one repository
for your entire application?
DaveFoderick
Yes. Typically a DAO ("data access object") is an
object that belongs to the layer between your domain
objects and their persistent datastore and has the
resposibility of marshalling data between the domain
objects and the datastore, encapsulating the domain
objects from the implementation details of the
datastore.
A repository, on the other hand, is a concept that
embodies a collection of contexts, aggregates, and/or
domain objects.
MatthewAdams
One repository per type of object.
EricEvans
Hi Matthew. Thank for the answer. Don't I know you from JDO-Central?
I'm not sure I understand your answer. It sounds to me like the DAO
description and the repository description are two ways of phrasing the same
idea.
What I have been doing is this. For each domain entity type (actually just
aggregate roots) I'll create a "home" interface. I'm using the term "home"
in the general sense, not the EJB sense. So, for example, I might have some
thing like this:
class Person{
...
}
interface PersonHome{
Person findById(String id)
Person[] findByLastName(String firstPartOfLastName)
void save(Person p)
...
}
class PersonHomeJdbc implements PersonHome{
//or PersonHomeJdo or PersonHomeHibernate
...
}
|
Thus, the Person class and the PersonHome interface are part of the domain
layer. The PersonHomeJdbc class is part of the data access layer. I've seen
the following names that seem to represent the same basic idea:
Home (EJB Spec)
Finder (Hibernate)
DAO (Sun)
Data Gateway (Fowler)
Data Mapper (Fowler)
Repository (Evans)
And I have to confess, I have pattern overload :) I'm still can't grasp the
distinction.
DaveFord
Hi Dave,
Yep, you know me from JDOCentral.
Anyhow, I said:
> A repository, on the other hand, is a concept that
> embodies a collection of contexts, aggregates, and/or
> domain objects.
I can see where you might have been confused, as the
term "repository" can get overloaded.
After reviewing Evans' notion of repository ("DDD: :Repository"), I
would say that a DDD: :Repository is a concept that allows the client
of the domain model to conveniently find aggregate root objects and
reconstitute them from the underlying datastore however they may.
JDO itself manifests a DDD: :Repository. If the intent of a
DDD: :Repository is to provide a convenient means for finding &
reconstituting objects, then you could use several features of JDO
for the finding part,
* the javax.jdo.Extent interface,
* the javax.jdo.Query interface,
* static finder methods that you write on your business objects that
use Extent or Query themselves, or
* stateless finder objects that you write that use Extent, Query, or
other means (other iterations, navigation, etc).
Of course, JDO takes care of the whole reconstituting responsibility
of DDD: :Repository, as that's its primary purpose.
JDO is a manifestation of DDD: :Repository and (Fowler?: :)DAO. In
JDO, enhancing a class to implement PersistenceCapable effectively
makes the domain object itself also a DAO, but it then delegates via
GoF: :Strategy to your JDO implementation's PersistenceManager,
StateManager, etc interface implementations for the actual persisting
and depersisting for your particular datastore type and vendor.
Further, since the developer never sees the PersistenceCapable
interface, and the class behaves as the unenhanced class in the
absence of the JDO framework, you don't have to consider or see this
code in your business objects.
MatthewAdams
Your PersonHome is like a Repository. Let's say it implemented findByID using a
ResultSet Adaptor that knew how to adapt the columns in the ResultSet to the
fields of a Person, e.g. return new PersonResultSetAdaptor().adapt(ResultSet
resultSet) where adapt() returns a Person. That Adaptor might be considered a
"Data Access Object".
RandyStafford
DAOVersusRepository is mentioned on: ThreadView
