s I write this,
four parts have been published in this series (see the
left column). Now is the time to focus on how to access the database.
As I said, what
we are going to talk about today is the Persistence Access layer, found slightly
to the right in Figure 1.
Those of you who are familiar with parts 1-4 will probably
notice that I’ve changed the name of one of the layers in Figure 1. My old
Application layer is now called Service layer instead so as to more closely
follow Martin Fowler’s names in his PoEAA book [5]. By this I mean that the
classes in my old Application layer were following the Service Layer pattern
and so I found that Service layer would be a better layer name.
Figure 1 The layer model
The
purpose of the Service layer [5] pattern is to provide a service-based view
on a Domain Model [5]. It’s also the case that the Service layer classes
will often contain some functionality of their own, and not only be a pass-through
to the Domain Model.
I have to admit
that changing the name of that layer after so many years was a painful decision
to take, but I think it is important to adjust to what I think is, or at least
will become, the de facto name standard.
The Persistence
Access layer itself is pretty similar to what I had in my book [7] two years
ago. The most important change is that I’m now working with a rich domain
model.
Talking
of changes, I’m also considering getting rid of the Shared
methods in the Persistence Access layer. (The reason for doing this is that
using Shared methods takes
away the possibility of using interfaces and the power of inheritance. I
think interfaces and inheritance come in handy here as a solution not only
for extending the functionality but also for extending testability.) But
I'll leave this for now, and will come back to it next time.
Digg
del.icio.us
Newvine
furl
StumbleUpon
BlinkList
Newsvine
Magnolia
Facebook
Tailrank
Slashdot
Technorati
Google Bookmarks
Yahoo Favorites
Windows Live
Ask
