Forget what I said. This is better.
FWIW -
Kevin
"Pruthee, Ranjan" <[EMAIL PROTECTED]> on 05/03/2002 03:25:15 PM
Please respond to "Struts Users Mailing List"
<[EMAIL PROTECTED]>
To: "Struts Users Mailing List" <[EMAIL PROTECTED]>
cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
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]>
---------------------------------------------------------------------------
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]>
