Creating DAO interfaces is a practice recommended by the J2EE Blueprints and
then creating implementations specific to the data source.
For example:
public interface CustomerDAO {
public CustomerVO create(CustomerVO vo) throws CustomerDAOException;
public void update(CustomerVO vO) throws CustomerDAOException;
...
}
//Oracle implementation
public class CustomerDAOOracleImpl implements CustomerDAO {
...
}
//SOAP implementation
public class CustomerDAOSOAPImpl implements CustomerDAO {
...
}
//Mainframe implementation
public class CustomerDAOCICSImpl implements CustomerDAO {
...
}
One approach may be to subclass an SQLDAO which implements the specified
interface and adds an abstract method resultsToObject() which maps an
java.sql.ResultSet to a ValueObject.
//abstract class
public abstract SQLDAO {
...
public abstract Object resultsToObject(ResultSet rs) throws SQLException;
}
// implementation
public class CustomerDAOSQLImpl extends SQLDAO implements CustomerDAO {
...
public Collection findAllCustomers() throws CustomerDAOException {
Collection collection = null;
try {
// get connection
// create statement
// execute statement and get results
while (rs.next()) {
CustomerVO object = (CustomerVO)
this.resultsToObject(rs);
collection.add(object);
}
} catch (Throwable t) {
throw new CustomerDAOException(t);
} finally {
// release resources
}
return collection;
}
public Object resultsToObject(ResultSet rs) throws SQLException {
if (rs == null) {
throw IllegalArgumentException("ResultSet cannot be null.");
}
CustomerVO object = null;
int id = rs.getInt(1);
String name = rs.getString(2);
String email = rs.getString(3);
object = new CustomerVO(id, name, email);
return object;
}
}
It has helped to isolate the data access code and reduce maintenance
problems.
robert
> -----Original Message-----
> From: Mike Duffy [mailto:[EMAIL PROTECTED]]
> Sent: Friday, May 03, 2002 6:20 PM
> To: Struts Users Mailing List
> Subject: RE: Forms Beans and DAO (Best Practices)
>
>
> Ranjan,
>
> Thank you for your insightful comments.
>
> Isn't it more likely that you would want to isolate the methods of
> your DAO so that this layer could be replaced? Passing back a
> Recordset may not be possible in some future data access layer (the
> data could come in as an XML doc or something else that needs to be
> "massaged" by the DAO). Keeping the DAO isolated seems more
> important than keeping it lightweight and independent.
>
> If the method "dao.getCustomer(String name)" returns a CutomerProfile
> object, you could create an interface for this method and any future
> data access layer could implement that interface. With this
> reasoning, creating the value objects in the dao seems like a good
> idea.
>
> You obviously have thought a great deal about this. I look forweard
> to your response.
>
> Thanks.
>
> Mike
>
>
> --- "Pruthee, Ranjan" <[EMAIL PROTECTED]> wrote:
> > The way I do it is -
> >
> > BO --> DAO --->returns the recordset and not ValueObject. This RS
> > is passed back to the BO. which passes it to the ValueObject to
> > build it.
> >
> > The code will look something like this -
> >
> > public class BO
> > {
> > CustomerVO custvo = new CustomerVO();
> > Recordset rs = dao.getCustomer(1);
> > custvo.buildCustomerVo(rs);
> > }
> >
> > One should not build VO in DAO because u will create dependency on
> > the DAO. In case u want to separate DAO from the BO then the DAO
> > alone will not work as it will have reference to the VO. So intead
> > of being a lightweight DAO it will be a heavyweight component will
> > lot of dependencies. Reuse will take hit with this approach but
> > that just me.
> >
> > Ranjan.
> >
> > -----Original Message-----
> > From: Jayaraman Dorai [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, May 03, 2002 3:07 PM
> > To: Struts Users Mailing List
> > Subject: RE: Forms Beans and DAO (Best Practices)
> >
> >
> > I use it the same way too. But had a dilemma of whether to place
> > the Value Object as a data member of Business Object and set that
> > in constructor or pass the Value Object as parameter for every
> > method of create, update, and remove. How do you do that? Any pros
> > and cons.
> >
> > -----Original Message-----
> > From: Pruthee, Ranjan [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, May 03, 2002 3:25 PM
> > To: Struts Users Mailing List
> > 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]>
> >
> >
> > --
> > To unsubscribe, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> > For additional commands, e-mail:
> > <mailto:[EMAIL PROTECTED]>
> >
>
>
> __________________________________________________
> 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]>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
