On Mon, 29 Jul 2002, Chappell, Simon P wrote:
> Date: Mon, 29 Jul 2002 14:06:03 -0500
> From: "Chappell, Simon P" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: Struts Users Mailing List <[EMAIL PROTECTED]>
> Subject: RE: Architecture advice....
>
> Well, what we did to seperate Struts from the backend was to implement
> what we called a "Firebreak". We created an abstract Java class called
> API.java. It's whole purpose in life was to be the application API to
> the model component. This would enable us to utilise alternative views
> and/or controllers if our needs ever took us in that direction.
>
Design pattern books call this the Data Access Object (DAO) pattern. It's
quite commonly implemented. The best scenaro is where your DAO object
returns JavaBeans that represent the underlying data (like customers and
orders), instead of just providing pass-through access to the connection
pool.
One of the big things I like about it is that the actual technology used
to store the persistent data (and any changes to it you make later) are
hidden from the business logic that uses the data.
For example, you might start out by embedding JDBC calls in your DAO to
load and store the data. Later on, your DBA might split one table into
two (or combine two into one) to improve efficiency -- you can tweak the
JDBC calls inside your DAO and never touch the business logic that uses
it. Later on, you might find it necessary to switch to EJBs for
scalability -- as long as you're not adding properties to the data
objects, these kinds of changes are transparent.
> All functionality in the application is accessable through static
> methods in the API class. This is nice for us, we removed all processing
> logic from the actions and put it in the main application space. Now our
> actions concentrate on ActionForms and calling the API methods.
>
Servlet context attributes can be thought of like "per-webapp statics",
because they have exactly the same memory impact. However, they provide
slightly more flexibility because you can subtitute different
implementations of the same API interface more easily. The negative is
that you have to have a reference to the ServletContext to acquire your
DAO object.
The standard J2EE approach to that is to use JNDI resources - they act
like static variables in that you can gain access to them directly,
without giving up the flexibility of using different implementations that
you can do with servlet context resources.
> To further the break between view and logic, we use Request and Reply
> objects to carry the data on the calls into and the return values back
> from the API.
>
Sounds a lot like another pattern, variously called "value objects" or
"data transfer objects".
> Simon
Craig
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
