On Mon, 29 Jul 2002, David Graham wrote:
> Date: Mon, 29 Jul 2002 15:15:46 -0600
> From: David Graham <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: [EMAIL PROTECTED]
> Subject: DAO Addition to struts
>
> Craig,
> 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 :-).
>
As popular as it might be, I've been a little hesitant to add model layer
patterns to the core part of Struts. After all, one of the values of
these patterns is you should be able to use the same DAO objects in
non-web contexts (so we wouldn't want to put in dependencies on servlet
and JSP, or even Struts, APIs). Also, putting *one* implementation of the
pattern into Struts would seem to imply that alternative implementations
are less legitimate -- and the spectrum of use cases for DAOs is so broad
that I'm not sure that is a good alternative.
There are DAO-like design patterns in some of the applications in the
"contrib" directory of the CVS repository, and in many of the apps
referenced on the resources page. And, of course, the DAO descriptions
from any competent patterns book should work just fine with Struts -- many
of them come with example code that can give you a starting point.
> Thanks,
> Dave
>
Craig
>
> >From: "Craig R. McClanahan" <[EMAIL PROTECTED]>
> >Reply-To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
> >To: Struts Users Mailing List <[EMAIL PROTECTED]>
> >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" <[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]>
>
>
>
>
> _________________________________________________________________
> MSN Photos is the easiest way to share and print your photos:
> http://photos.msn.com/support/worldwide.aspx
>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
