This is a really good description. I do have one small question, where does the connection pooling, transaction handling come into play? I know you use transactions in your BO but do you initialize this code in the DAOs? Do you use some sort of JNDI reference for your connection pooling? What is the best practice for this? I know there is datasources and connection pooling in struts, but shouldn't these things be in the data access objects?
Graham ----- Original Message ----- From: "Pruthee, Ranjan" <[EMAIL PROTECTED]> To: "Struts Users Mailing List" <[EMAIL PROTECTED]> Sent: Friday, May 03, 2002 4:25 PM Subject: RE: Forms Beans and DAO (Best Practices) > 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 ction 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 > > 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: Chen, Dean (Zhun) [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 03, 2002 2:23 PM > To: 'Struts Users Mailing List' > Subject: RE: Forms Beans and DAO (Best Practices) > > > This might be a stupid question, but what are DAO and Value Object supposed > to be? > > Does DAO encapsulate the logic to make JDBC calls? For example, would it > contain the name of a stored procedure or would that be passed to it? > > Is ValueObject a generic object that stores the result sets? For example, a > Collection of somesort? or a Collection of Collections? > > Thanks, I am also trying to figure out what the most performant way to > design this. > > > Dean Chen > > > > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > Sent: Friday, May 03, 2002 1:17 PM > To: Struts Users Mailing List > Subject: Re: Forms Beans and DAO (Best Practices) > > > > > > I see what you're doing and agree it seems easier. > > But coupling the form beans to the DAO's so tightly I wouldn't call a best > practice. Here is another approach: > > > - Have the DAO's return Value Objects. But then have a setValueObject() on > the form bean so you can store the entire value object in it. > > First, in your action class, do something like: > > myFormBean1.setValueObject1(myDao1.getValueObject1()); > > Then either, > > 1. Have your get/set methods for the form bean properties use the > value object for storage internally, like: > > // in the form bean.java file > > private ValueObject valueObject1 > public void setValueObject1(ValueObject val1) { > this.valueObject = val1; > } > > // Note: no property1 field needed! > public String getProperty1() { > return this.valueObject.getProperty1(); > } > public void setProperty1(String property1) { > this.valueObject.setProperty1(property1); > } > > > - or - > > 2. Have the setValueObject() in the form bean deconstruct the value > object and store its components in the form bean > > // again, in the form bean.java file > > // Note: no valueObject1 field needed! > public void setValueObject1(ValueObject val1) { > this.property1= val1.getProperty1(); > } > > private String property1; > public String getProperty1() { > return this.valueObject.getProperty1(); > } > > > Another alternative would be to put a "facade" in front of multiple DAO's > to simplify the actoin class and decouple it from the back end data > sources. > > // In MyAction.java > > int id = 123; // id is key into back end systems > MyFacade facade = new MyFacade(); > MyFormBean formBean1 = facade.getFormBean(id); > > // Then in the facade, have something like: > > public MyFormBean (int identifier) { > > MyFormBean mfb = new MyFormBean(); > > MyDao1 dao1 = new MyDao1 (); > mfb.setDao1Vals(dao1.getVals(id)); > > MyDao2 dao2 = new MyDao2 (); > mfb.setDao2Vals(dao2.getVals(id)); > > MyDao3 dao3 = new MyDao3 (); > mfb.setDao3Vals(dao3.getVals(id)); > > return mfb; > } > > This decouples the FormBean and the Action class from the structure > of the DAOs and the back-end sysems. > > > > Given all this, I like the first approach above the best..... > > > FWIW - > Kevin > > > > > > Mike Duffy <[EMAIL PROTECTED]> on 05/03/2002 11:50:37 AM > > Please respond to "Struts Users Mailing List" > <[EMAIL PROTECTED]> > > To: [EMAIL PROTECTED] > cc: (bcc: Kevin Bedell/Systems/USHO/SunLife) > Subject: Forms Beans and DAO (Best Practices) > > > I am pre-populating a form with information from a data base. > > Is the following procedure acceptable, or is there another procedure > that would be considered a "Best Practice"? > > Instantiate the form bean in the action class. > > Instantiate one or more DAO objects in the action class. > > Call methods in the DAO objects that would take the form bean as an > argument and fill up the necessary fields. > > I understand the need to keep layers separate; however, if I am just > trying to fill up the fields in a form, it seems unnecessary to have > the DAO objects return data objects and then call a series of > "get/set" methods to take the data from the data objects and put it > in the form bean. > > Thanks. > > __________________________________________________ > Do You Yahoo!? > Yahoo! Health - your guide to health and wellness > http://health.yahoo.com > > -- > To unsubscribe, e-mail: < > mailto:[EMAIL PROTECTED]> > For additional commands, e-mail: < > mailto:[EMAIL PROTECTED]> > > > > > > > > -------------------------------------------------------------------------- - > This e-mail message (including attachments, if any) is intended for the use > of the individual or entity to which it is addressed and may contain > information that is privileged, proprietary , confidential and exempt from > disclosure. If you are not the intended recipient, you are notified that > any dissemination, distribution or copying of this communication is > strictly prohibited. If you have received this communication in error, > please notify the sender and erase this e-mail message immediately. > -------------------------------------------------------------------------- - > > > -- > 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]>
