struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "David Graham" <>
Subject DAO Addition to struts
Date Mon, 29 Jul 2002 21:15:46 GMT
You mentioned the DAO pattern in this last post on architectures.  I'm 
wondering if you have any plans on adding a DAO framework to struts?  I 
think it would be a nice addition and provide something that many people 
have to design themselves.  I suppose it may be outside of the scope for 
struts but I'll leave that up to you :-).


>From: "Craig R. McClanahan" <>
>Reply-To: "Struts Users Mailing List" <>
>To: Struts Users Mailing List <>
>Subject: RE: Architecture advice....
>Date: Mon, 29 Jul 2002 14:09:46 -0700 (PDT)
>On Mon, 29 Jul 2002, Chappell, Simon P wrote:
> > Date: Mon, 29 Jul 2002 14:06:03 -0500
> > From: "Chappell, Simon P" <>
> > Reply-To: Struts Users Mailing List <>
> > To: Struts Users Mailing List <>
> > 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
> > 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
>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
>To unsubscribe, e-mail:   
>For additional commands, e-mail: 

MSN Photos is the easiest way to share and print your photos:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message