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]>
