Ranjan and company,
If you don't mind I have a couple questions about this list Ranjan
proposed. After this list I have posted my questions/comments:
PR> 1. Client sends HTTP request
PR> 2. Struts delegates request to ShowCustomersAction
PR> 3. ShowCustomersAction delegates to CustomerBO
PR> 4. CustomerBO starts a transaction
PR> 5. CustomerBO delegates to CustomerDAO
PR> 6. CustomerDAO executes the query and gets results
PR> 7. CustomerDAO maps results into a collection of CustomerDTO
PR> (DataTransportObject)
PR> 8. CustomerDAO returns collection to CustomerBO
PR> 9. CustomerBO ends transaction
PR> 10. CustomerBO returns collection to ShowCustomerAction
PR> 11. ShowCustomersAction places the connection in the HttpServletRequest as
PR> an attribute
PR> 12. ShowCustomersAction forwards to showCustomersView (some jsp)
PR> 13. ShowCustomersView accesses customer collection using a custom tag
PR> 14. ShowCustomersView renders customer list
Rick's questions...
1) In a later post you mention that you don't like your DAO's
returning DTOs but rather have them return record sets. In this
list (steps 6 - 8 ) it looks like you are having the DAO return a
Collection of DTOs. I'm a bit confused there, since later below in
the thread you seem to mention that this a bad idea (unless I'm
mistaken).
2) If a DAO shouldn't be tied to any specific DTOs (or Value
Objects) then who should updates or inserts be taken care of ? In
other words if you need to have a DAO update or insert an Employee
type object, what do you recommend passing the DAO from your
business layer in order to accomplish this? In other words say a
DTO captures both some Employee information plus also holds some
Customer Survey information.
Where in the architecture do I strip out what I need from the DTO
in order to do the insert of the Employee based on the employee
information contained in the DTO? or should I not even care about
that and just assume that if the business rules change ( for
example, I no longer need the DTO to also have some Customer
survey information ) that I must then have to code a new DAO to
deal with the new requirements?
The layer where I'm still having the most confusion is this layer
of getting what is captured in the DTO or Value Object over to the
place where the database insert/update really takes place (DAO?).
If a DAO, or some repository where you have your SQL, is not
supposed to take a DTO, I'm confused how to handle it.
Someone tell me what is wrong with this proposal: (Lets say
inserting Employee information and also inserting some Survey
information that is captured from a form ).
Action class
[ creates DTO containing employee and survey information
and then calls a Business Object method:
BO.doInsert( DTO myDTO ) ]
BO
[ has method doInsert( DTO myDTO ) which here I would strip
out what I need from the DTO and then call the appropriate
DAOs and methods. For example:
EmployeeDAO.insertEmployee( myDTO.getName(),
myDTO.getAddress(), etc );
SurveyDAO.insertSurvey( myDTO.getEmployeeName(), myDTO.getAnswer1(),
myDTO.getAnswer2(), etc );
]
DAOs [ with methods like above that do the inserts into the DB ]
I rarely see the above being done where the attributes are passed
in as method arguments to the DAOs, so I'm guessing there are some
serious drawbacks to it. I'd love some help here.
Thanks so much.
Rick
=== MAIN THREAD BELOW =====
On Thursday, May 16, 2002, 12:14:38 PM, Ranjan wrote:
PR> Here u go - read the entire email and u will understand...this
PR> from the previous thread discussed couple of weeks ago...
PR> How do you create a customer. (i.e.) Add a new record in the database from the
data entered in the HTML client.
PR> The way I currently do is
PR> 1. The action form has the Value Object
PR> 2. The action class gets the Value Object through the action form. Then Calls
BO.create(VO)
PR> 3. The Business Object then calls the DAO.create(VO).
PR> The same for updating the BO in the edit mode ( through BO.update(VO) which then
calls DAO.update(VO).
PR> Jayaraman
PR> -----Original Message-----
PR> From: Pruthee, Ranjan [mailto:[EMAIL PROTECTED]]
PR> Sent: Friday, May 03, 2002 4:23 PM
PR> To: Struts Users Mailing List
PR> Subject: RE: Forms Beans and DAO (Best Practices)
PR> 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.
PR> The code will look something like this -
PR> public class BO
PR> {
PR> CustomerVO custvo = new CustomerVO();
PR> Recordset rs = dao.getCustomer(1);
PR> custvo.buildCustomerVo(rs);
PR> }
PR> 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
PR> 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.
PR> Ranjan.
PR> -----Original Message-----
PR> From: Jayaraman Dorai [mailto:[EMAIL PROTECTED]]
PR> Sent: Friday, May 03, 2002 3:07 PM
PR> To: Struts Users Mailing List
PR> Subject: RE: Forms Beans and DAO (Best Practices)
PR> 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
PR> method of create, update, and remove. How do you do that? Any pros and cons.
PR> -----Original Message-----
PR> From: Pruthee, Ranjan [mailto:[EMAIL PROTECTED]]
PR> Sent: Friday, May 03, 2002 3:25 PM
PR> To: Struts Users Mailing List
PR> Subject: RE: Forms Beans and DAO (Best Practices)
PR> 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
PR> (DataTransportObject [use to be ValueObject]). In this fashion, I can keep my
business logic reusable in say a Java
PR> 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
PR> 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
PR> follows:
Client ===>> XXXXAction ===> BusinessObject ===> DataAccessObject(s) ===> Database
PR> 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
PR> 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
PR> creation)
PR> So for example if I wanted to retrieve and display a customer list.
PR> 1. Client sends HTTP request
PR> 2. Struts delegates request to ShowCustomersAction
PR> 3. ShowCustomersAction delegates to CustomerBO
PR> 4. CustomerBO starts a transaction
PR> 5. CustomerBO delegates to CustomerDAO
PR> 6. CustomerDAO executes the query and gets results
PR> 7. CustomerDAO maps results into a collection of CustomerDTO
PR> (DataTransportObject)
PR> 8. CustomerDAO returns collection to CustomerBO
PR> 9. CustomerBO ends transaction
PR> 10. CustomerBO returns collection to ShowCustomerAction
PR> 11. ShowCustomersAction places the connection in the HttpServletRequest as
PR> an attribute
PR> 12. ShowCustomersAction forwards to showCustomersView (some jsp)
PR> 13. ShowCustomersView accesses customer collection using a custom tag
PR> 14. ShowCustomersView renders customer list
PR> 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.
PR> -----Original Message-----
PR> From: Chen, Dean (Zhun) [mailto:[EMAIL PROTECTED]]
PR> Sent: Friday, May 03, 2002 2:23 PM
PR> To: 'Struts Users Mailing List'
PR> Subject: RE: Forms Beans and DAO (Best Practices)
PR> This might be a stupid question, but what are DAO and Value Object supposed
PR> to be?
PR> Does DAO encapsulate the logic to make JDBC calls? For example, would it
PR> contain the name of a stored procedure or would that be passed to it?
PR> Is ValueObject a generic object that stores the result sets? For example, a
PR> Collection of somesort? or a Collection of Collections?
PR> Thanks, I am also trying to figure out what the most performant way to
PR> design this.
PR> Dean Chen
PR> -----Original Message-----
PR> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]
PR> Sent: Friday, May 03, 2002 1:17 PM
PR> To: Struts Users Mailing List
PR> Subject: Re: Forms Beans and DAO (Best Practices)
PR> I see what you're doing and agree it seems easier.
PR> But coupling the form beans to the DAO's so tightly I wouldn't call a best
PR> practice. Here is another approach:
PR> - Have the DAO's return Value Objects. But then have a setValueObject() on
PR> the form bean so you can store the entire value object in it.
PR> First, in your action class, do something like:
PR> myFormBean1.setValueObject1(myDao1.getValueObject1());
PR> Then either,
PR> 1. Have your get/set methods for the form bean properties use the
PR> value object for storage internally, like:
PR> // in the form bean.java file
PR> private ValueObject valueObject1
PR> public void setValueObject1(ValueObject val1) {
PR> this.valueObject = val1;
PR> }
PR> // Note: no property1 field needed!
PR> public String getProperty1() {
PR> return this.valueObject.getProperty1();
PR> }
PR> public void setProperty1(String property1) {
PR> this.valueObject.setProperty1(property1);
PR> }
PR> - or -
PR> 2. Have the setValueObject() in the form bean deconstruct the value
PR> object and store its components in the form bean
PR> // again, in the form bean.java file
PR> // Note: no valueObject1 field needed!
PR> public void setValueObject1(ValueObject val1) {
PR> this.property1= val1.getProperty1();
PR> }
PR> private String property1;
PR> public String getProperty1() {
PR> return this.valueObject.getProperty1();
PR> }
PR> Another alternative would be to put a "facade" in front of multiple DAO's
PR> to simplify the actoin class and decouple it from the back end data
PR> sources.
PR> // In MyAction.java
PR> int id = 123; // id is key into back end systems
PR> MyFacade facade = new MyFacade();
PR> MyFormBean formBean1 = facade.getFormBean(id);
PR> // Then in the facade, have something like:
PR> public MyFormBean (int identifier) {
PR> MyFormBean mfb = new MyFormBean();
PR> MyDao1 dao1 = new MyDao1 ();
PR> mfb.setDao1Vals(dao1.getVals(id));
PR> MyDao2 dao2 = new MyDao2 ();
PR> mfb.setDao2Vals(dao2.getVals(id));
PR> MyDao3 dao3 = new MyDao3 ();
PR> mfb.setDao3Vals(dao3.getVals(id));
PR> return mfb;
PR> }
PR> This decouples the FormBean and the Action class from the structure
PR> of the DAOs and the back-end sysems.
PR> Given all this, I like the first approach above the best.....
PR> FWIW -
PR> Kevin
PR> Mike Duffy <[EMAIL PROTECTED]> on 05/03/2002 11:50:37 AM
PR> Please respond to "Struts Users Mailing List"
PR> <[EMAIL PROTECTED]>
PR> To: [EMAIL PROTECTED]
PR> cc: (bcc: Kevin Bedell/Systems/USHO/SunLife)
PR> Subject: Forms Beans and DAO (Best Practices)
PR> I am pre-populating a form with information from a data base.
PR> Is the following procedure acceptable, or is there another procedure
PR> that would be considered a "Best Practice"?
PR> Instantiate the form bean in the action class.
PR> Instantiate one or more DAO objects in the action class.
PR> Call methods in the DAO objects that would take the form bean as an
PR> argument and fill up the necessary fields.
PR> I understand the need to keep layers separate; however, if I am just
PR> trying to fill up the fields in a form, it seems unnecessary to have
PR> the DAO objects return data objects and then call a series of
PR> "get/set" methods to take the data from the data objects and put it
PR> in the form bean.
PR> Thanks.
PR> -----Original Message-----
PR> From: Damien VIEL [mailto:[EMAIL PROTECTED]]
PR> Sent: Thursday, May 16, 2002 11:01 AM
PR> To: Struts Users Mailing List
PR> Subject: DAO- BO in Struts
PR> Hi,
PR> Can someone explain me "simply" how work DAO and BO classes in Struts.
PR> What are their links with the Form object the Action object.
PR> We can take this example :
PR> First, there is a login page that check from a DataBase if a User (Object)
PR> can login.
PR> Then the user enter into the website and add a Product (Object) in a
PR> HashTable which is a variable of the User object. This product is also added
PR> to the database.
PR> What are the role of the UserBO.java, UserDAO.java, ProductBO.java,
PR> ProductDAO.java, User.java, Product.java ?
PR> Thanks
PR> Dams
PR> --
PR> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
PR> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
PR> --
PR> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
PR> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
--
Rick
mailto:[EMAIL PROTECTED]
"I bet a fun thing would be to go way back in time to where there was
going to be an eclipse and tell the cave men, 'If I have come to
destroy you, may the sun be blotted out from the sky.' Just then the
eclipse would start, and they'd probably try to kill you or something,
but then you could explain about the rotation of the moon and all, and
everyone would get a good laugh."
-Jack Handey
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
