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