At 04:31 PM 6/30/2005, Bryan wrote:
>I have recently joined a project that wishes to encapsulate all data access
>within "data services". A data service will contain one or more DAO's, which
>will generally use Hibernate to map a transfer object model to tables. These
>data services are intended to be topic based, and will be findable using a
>service locater pattern.
I wrote about this strategy in Agile Database Techniques and summarized it
if it helps.
>This is an architecture I have not used before in the persistance layer.
>Generally, I've taken an approach that simply makes DAO's reuseable across
>business services, possibly with a DAO factory to manage construction and
>common configurations. My first question is whether anybody has used a similar
>data services approach and if anybody has any references that explain when and
>why this data services architecture might be useful and how it compares to a
>simple-minded "reuse the DAO's directly approach".
This is a higher level level of encapsulation that DAOs, IMHO, assuming that:
1. You use a services technology that is reusable on several
platforms. For example, writing Java services around Java DAOs doesn't buy
you much, writing Web Services around Java DAOs does.
2. You can get the interface of the services right. For example, there
wouldn't be much value writing four CRUD services for each DAO, there would
be value in creating a SaveOrder() service which saves an XML structure
representing an Order, Customer info, and Order Item info using the
>Second, I am wrestling with the question of how fine or coursed grained to
>my data services, which effectively is a question of how to scope the
> This could range anywhere from having one service per DAO to one data
>per database. Any advice or experience here would be appreciated.
You need to understand the usage which you need to support (e.g. do some
use case modeling, perhaps some user stories). If you just do data
modeling you're pretty much guaranteed to get it wrong because it's not
data that you need to model here, it's services.
One way to identify services is overviewed at
you can see, it indicates the potential need for business services such as
check to see if student exists, verify that a person is eligible to enroll,
add applicant to database, and calculate enrollment fees. To support these
services you would need to access the database. Whether you want to do
that directly through DAOs, or through a layer of "pure data services",
whatever that implies, is up to you. Arguably the first and third business
service that I listed are mostly data services, at least on the surface.
I would lean towards a one service uses multiple DAOs approach, with many
services being written. But I really don't know anything about your
environment so take that advice with a grain of salt.
Scott W. Ambler
Senior Consultant, Ambysoft Inc.
www.agiledata.org -:- www.agilemodeling.com -:- www.ambysoft.com -:-
www.databaserefactoring.com -:- www.enterpriseunifiedprocess.com -:-