Ok, I can live without DAO being part of struts. Thanks, Dave
> >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]> _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
