On Saturday, May 4, 2002, 4:55:02 PM, Struts Newsgroup wrote:
SN> <[EMAIL PROTECTED]> === (great thread) If #1 is
SN> prefered, can somone please coment as to the practical value of
SN> the valueObject layer if one is not doing EJB. Why not:
SN> myFormBean.setDAO(myDAO.retSelf());
Vic, do you have an example of this at the basebeans site? I'm
still trying to get a handle on what specifically is done in the
business objects and what is specifically done in the DAO objects.
Just a couple questions I'd like to throw out there..
1) First what methods should be in a DAO. In other words if you
are dealing with Employees, should the DAO do everything related
to an Employee ie. insertEmployee, getEmployees,
getSingleEmployee, updateEmployee ?
2) What should the methods in the DAOs return? Are they returning
ResultSets to the Business Objects? Collections of beans?
Thanks for any more feedback.
--Rick
SN> This allows me to unit test the dao (DAO in my case has a SQL string and
SN> CachedRowSet). This allows me to unit test the bean, without Struts or
SN> action classes.
SN> It also allows me to re-use the bean outside of Struts (ex: SOAP, so VB
SN> applications can read it on client side).
SN> Vic
SN> OT: I think anything that does not allow you to unit test DAO or Bean
SN> without action class is not best practice. Anything that assumes you are
SN> using EJB is not best practice. IMHO
>>
>> 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.
>>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
