----- Original Message -----
From: "Sasha Borodin" <[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
Sent: Friday, October 10, 2003 8:33 PM
Subject: Re: Keeping Actions clean - separating actions from businessmodel
from persistence
> Matt, thanks for your quick feedback.
>
> > I use my own framework because I don't know any better.
> >
> > public abstract class DaoManager {
> > public abstract IRecordDao createDao(Connection conn, String
daoClassName)
> > throws DaoException;
>
> Which tier calls your DaoManager? It seems from your code that the caller
> of DaoManager is responsible to knowing the database configuration
> information, as well as the implementing DAO class. Is it the Action?
I have a 4 tier architecture.
PRESENTATION TIER
- Struts
- Action classes
BUSINESS TIER
- Business Objects
INTEGRATION & PERSISTENCE TIER
- DAO Manager
- DAOs
- Other database access mechanisms (I do some JDBC using a fancy home-grown
SQL building mechanism when dealing with particularly complex queries)
RESOURCE TIER
- Databases
In addition to the 4 tiers, my applications are separated into two parts.
One part is a reusable framework that is shared among many applications.
The second part is the actual application code that is specific to a single
application because of business rules, etc. (Even if you don't need a
reusable framework for your work, such a thing can be useful because it
allows you to do things like swap out your persistence mechanism without
disturbing your presentation code and business objects)
A single Abstract Factory (informally called Walmart) is responsible for
creating the DAO manager and the business objects in the reusable framework.
The application code must define a concrete implementation of the Abstract
Factory. This implementation must know how to create a DAO Manager that
works with the persistence mechanism being used.
So, to finally get around to answering your question, the caller of the DAO
manager does not need to know anything about the persistence mechanism used.
The DAO manager's job is to hide this information from its clients.
True, the application code does need to provide the implementation of the
Abstract Factory and an implementation of the DAO manager. However, since
the DAO manager is an abstract class, its clients can rely only on the API
of the DAO manager rather than relying on the API of the underlying
persistence mechanism. Thus the clients of the DAO manager need not know
anything about the persistence mechanism being used. So even though the
application does have to specify what persistence mechanism is used and how
to interact with that mechanism, that definition is in *one place* which
means that it can be changed if need be without impacting the business
objects.
> In other words, who orchestrates the interaction of business and dao
> classes? Does the action instantiate a business class and populate it
from
> your ActionForm, then get a dao instance from a factory, and pass it the
> business class? Or is there another pattern to this?
The exact interactions among the components of course depend on the business
rules. A typical use case is that the Action class creates a few DAOs based
on information in the request and then passes those DAOs to one of the
business objects. The business objects may in turn retrieve other DAOs,
create DAOs, or even return DAOs to the Action class for further processing
by another business object.
Well that was rather long-winded... did I answer your question or go off on
a useless tangent? ;)
Matt
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
