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 :-).
Thanks, Dave >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]>
