Database Reference
In-Depth Information
Although this code isn't quite as clean as it could be, it does the job. In the next section
you'll see how entities can be looked up via repositories, which does an even better job of
hiding all internal plumbing required to perform index lookups as well as other functions.
9.3.3. Repositories
The second main option for loading and saving entities is via an implementation of the
re-
pository pattern
, which you can find discussed in various topics, including
Domain Driven
Design
byEricEvans(Addison-WesleyProfessional,2003)and
Patterns of Enterprise Ap-
plication Architecture
by Martin Fowler (Addison-Wesley Professional, 2002).
In simple terms, a repository provides an abstraction layer between your business code,
which should generally be dealing with domain-level entities, and all the logic required to
convert these entities to and from their formats in any underlying data stores. Your busi-
nesscodeshoulddealinthelanguageofthedomain;howthesedomainentitiesareactually
loaded and saved is a job for a particular repository implementation. Using this approach,
if you decided to swap out your data store, you wouldn't need to throw away all of your
business code; rather, you'd replace the appropriate repository implementation with one
that knows how to translate the domain entities to and from the new data store format.
SDN repositories have specifically been designed to focus on one domain class at a time,
and they aim to provide a whole range of default operations specific to that domain class.
The really nice feature of SDN repositories is that they don't require you to write a single
line ofcode to implement the default operations. All youneed dois define an interface and
specify which domain class you'd like these operations created for.
Using the
User
domain class as an example, let's look at how this works and what's in-
volved.
Figure 9.6
shows our starting point.
