We are also using the DAO/buslogic/action tiers as described in the messages below. We've been careful to ensure that only the business logic classes call any DAO methods - never the Action classes.
For the DAO layer, I've found it easy enough to use jdbc to write a single query that joins multiple tables into a ResultSet, then create multiple related objects from that single ResultSet. For saving the data back to the database I have to pull apart the objects and save the data with multiple update and/or insert statements. This is a "roll-your-own" object-relational mapping. If you're interested in commercial products that do object-relational, they typically map one object to one table, and this can result in lower performance due to multiple requests to the DB for each table, rather than a single request that joins the tables and brings back all the data in one query. These tools do have their advantages, though. You don't need to know anything about SQL, relational databases, transaction management, and very little about JDBC as they sit on top of JDBC and do most of the work for you. Toplink and the JDO reference implementation (formerly JavaBlend, now included in Forte for Java from Sun) are two examples of commercial products. There are also containers from some of the Object database vendors available that do essentially the same thing. Typically all of these products will work with Oracle, MS SQL Server and Sybase - some will also work with DB2 and other RDBMS products. Someone mentioned Torque for Turbine in this thread, I haven't used it but experimented a little with other Turbine classes briefly and it seems like a good alternative to commercial products (it is part of apache jakarta). follow this for more info on the commercial stuff: http://www.object-relational.com/object-relational.html -----Original Message----- From: Francisco Hernandez [mailto:[EMAIL PROTECTED]] Sent: Wednesday, April 17, 2002 11:38 AM To: Struts Users Mailing List Subject: Re: Design Advice - Relational Databases & Java Objects. 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]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
