Also, You might find the following links useful:
http://java.sun.com/blueprints http://java.sun.com/blueprints/code/jps13/src/index.html Mike --- Rick Reumann <[EMAIL PROTECTED]> wrote: > 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]> > __________________________________________________ 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]>
