Thanks all for your responses to this topic. I have been trying to
find more concrete examples of using DAO's on the internet but haven't
been having a lot of luck. If someone has links they could share that
aren't too heavily laden with EJB technologies I'd appreciate them. In
the meantime I hope what I have below isn't too much in the RTFM
territory...
Before I get into my specific questions with Ranjan's last post,
let me just quickly define, (which I'm sure is the wrong way), what
I've set up so far.
I'll try to stick with the previous example of dealing with a
customer.
1) JSP --- >
2) CustomerFormBean --- >
3) CustomerEditAction (just using EditAction as an example)
Now currenlty what I'm doing in here is probaly wrong.
//convert the CustomerFormBean (which has all String fields into a
//CustomerBean which has proper fields ..Date, int, etc )
CustomerBean customer =
SomeUtilityClass.convertCustomerFormBean( CustomerFormBean )
//call business object with a real customer bean
--boolean success CustomerBO.editCustomer( customer )
--Collection customers = CustomerBO.getAllCustomers()
forward to page that might show the customers collection
Now I'm sure a major problem is in my CustomerBO. My CustomerBO is not
calling it a DAO, so obviously I must be doing too much in the
CustomerBO. I choose to put the customer methods in this class since
it seemed nice to have all the SQL pertaining to dealing with
customers in one place. I think I now see the possible problems of not
separating things out. In a simple case above it's not really a big
deal. But someone correct me if I'm wrong, say it was something like
CustomerBO.processTheirWholeLifeStory(). This method might invovle
several calls to different types of business things going on, not just
one simple SQL query or update.
To break the above out correctly for getting the Collection of
Customers maybe I should be doing something like...
Collection customers = CustomerBO.getAllCustomers();
Then in CustomerBO...
public Collection getAllCustomers() {
ResultSet rs = CustomerDAO.getAllCustomers(
pass in Connection here or get handle to it
in the DAO ??? )
//loop
return Collection
OR is it better to actually return the Collection from the DAO?
Collection c = CustomerDAO.getAllCustomers(.. )
Now with the screwed up mindset I probably have Ranjan, if you don't
mind let me ask some questions about the list you presented:
1. Client sends HTTP request
ok
2. Struts delegates request to ShowCustomersAction
ok
3. ShowCustomersAction delegates to CustomerBO
Just so I'm following you this is where you might call:
CustomerBO.getCustomers() ? ( What if it was an edit customer
would you pass the whole CustomerFormBean off to the CustomerBo ?)
4. CustomerBO starts a transaction
So, CustomerBO actually does the getting of the Connection and
maybe gets out of the FormBean what parameters it needs to pass
to the DAO?
5. CustomerBO delegates to CustomerDAO
CustomerBO maybe then calls something like
ResultSet rs =
CusotmerDAO.getCustomerCollection ( Connection?, args ) ?
6. CustomerDAO executes the query and gets results
(mentioned above)
7. CustomerDAO maps results into a collection of CustomerDTO
(DataTransportObject)
I'm confused what's going on here. I'm not so sure what a
DTO is. It looks like here the DAO would then actually be
returning a Collection of concrete Customer objects. If this is
correct, am I following that the main purpose of the CustomerBO
then is just get the arguments and maybe a handle to a Connection
that the DAO needs in order to in this case just get the
Collection of Customers.
( I follow the rest )
Thanks so much for your guys' time.
On Friday, May 3, 2002, 3:25:15 PM, Pruthee, Ranjan wrote:
PR> In general, I use the Struts action classes as proxies to my
PR> business objects and my business objects serve as proxies to my
PR> data access objects and I pass data across tiers using DTO
PR> (DataTransportObject [use to be ValueObject]). In this fashion, I
PR> can keep my business logic reusable in say a Java Swing client as
PR> well as an HTML client. IMO, I would not access DAO (data access
PR> objects) directly in the Struts ction classes. This means you
PR> would have to manage transaction boundries (getting JDBC
PR> connection or JDO PersistanceManager) in your web tier where as it
PR> would probably be better to isolate these details to your business
PR> tier. We don't use EJB, so the general data flow is as follows:
Client ===>> XXXXAction ===> BusinessObject ===> DataAccessObject(s) ===> Database
PR> This keeps BusinessObjects resuseable among XXXXAction classes and
PR> DAO objects reusable in BusinessObjects. The BusinessObject
PR> manages the transaction boundries and the DAO just uses the JDBC
PR> connection. We maintain all SQL as static final Strings in the
PR> DAO's. (reduces object creation) The BusinessObjects and DAO don't
PR> 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
PR> 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
PR> BusinessDelegates to actual EJBs and nothing in the web tier has
PR> to change and both DAOs and DTOs can be reused.
--
Rick
mailto:[EMAIL PROTECTED]
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
