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