excellent explanation, this should be of help to many people and exactly as I have implemented it in my own apps.
----- Original Message ----- From: "Robert Taylor" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Wednesday, April 17, 2002 4:41 AM Subject: RE: Design Advice - Relational Databases & Java Objects. > Rob, > > Sun's blue prints are an excellent resource to get an idea of how to handle > data access via the web tier. > In general, I use the Struts action classes as proxies to my business > objects and my business objects serve > as proxies to my data access objects and I pass data across tiers using DTO > (DataTransportObject [use to be ValueObject]). > In this fashion, I can keep my business logic reusable in say a Java > Swing client as well as an HTML client. > > IMO, I would not access DAO (data access objects) directly in the Struts > action classes. This means you > would have to manage transaction boundries (getting JDBC connection or JDO > PersistanceManager) > in your web tier where as it would probably be better to isolate > these details to your business tier. > > We don't use EJB, so the general data flow is as follows: > > Client ===> XXXXAction ===> BusinessObject ===> DataAccessObject(s) ===> > Database > > > This keeps BusinessObjects resuseable among XXXXAction classes and DAO > objects reusable in BusinessObjects. > The BusinessObject manages the transaction boundries and the DAO just uses > the JDBC connection. > We maintain all SQL as static final Strings in the DAO's. (reduces object > creation) > The BusinessObjects and DAO don't maintain any state, so they are > singletons. (reduces object creation) > > So for example if I wanted to retrieve and display a customer list. > > 1. Client sends HTTP request > 2. Struts delegates request to ShowCustomersAction > 3. ShowCustomersAction delegates to CustomerBO > 4. CustomerBO starts a transaction > 5. CustomerBO delegates to CustomerDAO > 6. CustomerDAO executes the query and gets results > 7. CustomerDAO maps results into a collection of CustomerDTO > (DataTransportObject) > 8. CustomerDAO returns collection to CustomerBO > 9. CustomerBO ends transaction > 10. CustomerBO returns collection to ShowCustomerAction > 11. ShowCustomersAction places the connection in the HttpServletRequest as > an attribute > 12. ShowCustomersAction forwards to showCustomersView (some jsp) > 13. ShowCustomersView accesses customer collection using a custom tag > 14. ShowCustomersView renders customer list > > > I'm sure everyone has there own way of accomplishing the use case above, but > this is how I have approached it. > > HTH, > > robert > > PS. If we did switch to using EJB, then the BusinessObjects become > BusinessDelegates to actual EJBs and > nothing in the web tier has to change and both DAOs and DTOs can be reused. > > > > -----Original Message----- > > From: rob [mailto:[EMAIL PROTECTED]] > > Sent: Wednesday, April 17, 2002 6:31 AM > > To: [EMAIL PROTECTED] > > Subject: Design Advice - Relational Databases & Java Objects. > > > > > > I'm hoping that as many people as possible will contribute their > > own personal > > experience and methods to this post. > > > > I have a relational database that contains information used to > > build java objects > > during runtime, I'm curious about: > > > > - In what classes in struts do people typically connect to > > the database > > and build java objects from the database. > > - Do the objects have interfaces which receive database connections > > and build themselves from the inside out? or do > > people make the > > necessary querys for the information and then pass > > the data to the > > constructor? > > - Any other methods or ideas that might aide my goal of elegance > > (and simplicity). > > > > Please be verbose I'm trying to find an elegant way to do it and > > though I've tried > > both perhaps someone here can offer some insight. > > > > Examples, Explanations all appreciated. > > > > Thanks > > > > > > -- > > 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]> > > -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
