Jim, Nice docs. Matt - You can also have a look at the code example from the book (Core J2EE Patterns), available at: http://www.phptr.com/corej2eepatterns/codeChap8.html
As for the overkill issue...yes, in some cases it is, but since it also helps address centralized access to the biz tier, exception translation (ie: network exceptions to application exceptions), synching or retries on invocations to biz tier if needed, managing caching, hiding impl details of biz service (ie: remote objects), encapsulating/hiding lookup of biz service (ie: ejbhome), it is a very valuable pattern to consider. Thanks, -dm "Cakalic, James" wrote: > Here are some example sequence diagrams I found that might be useful: > http://www.cayambe.org/docs/design/AddToCart.html > http://www.cayambe.org/docs/design/BrowseCatalog.html > http://www.cayambe.org/docs/design/ManageCart.html > http://www.cayambe.org/docs/design/ViewReceipt.html > > The use cases that these sequence diagrams design are here: > http://www.cayambe.org/docs/requirements/Use_Case.html > > I'll see what else I can dig up later. > > Jim > > > -----Original Message----- > > From: Matt Raible [mailto:[EMAIL PROTECTED]] > > Sent: Tuesday, February 26, 2002 1:58 PM > > To: Struts Users Mailing List > > Subject: RE: DB Access from Struts > > > > > > Any examples of a Business Delegate class out there - I'm > > thinking of using a > > similar pattern to the one below, rather than calling my > > DAO's directly from my > > action class. > > > > Is this just a regular class that calls the DAOs? I'm > > assuming so? Any ideas > > on naming? > > > > Also, has anyone implemented this pattern with the > > DispatchAction class in > > Struts? > > > > Thanks, > > > > Matt > > > > --- "Cakalic, James" <[EMAIL PROTECTED]> wrote: > > > It may seem like a long way around for some, but the > > pattern I have been > > > applying is to keep the ActionForm classes as presentation > > objects, have > > > "data model" classes that represent the fields in the database for > > > persistence, and between these, have value objects that > > represent the true > > > "object model" with which you want to operate. Mixing these > > three concepts > > > together is, IMO, what generally gets one into problems related to > > > incomplete separation between layers. > > > > > > As for responsibilities, I introduce a business delegate > > between the Action > > > and the persistence in which the actual "work" -- the use > > cases/user stories > > > implemented by your system -- is performed. The > > responsibility of the Action > > > is to translate between the presentation objects > > (ActionForms) and the value > > > objects used by the delegate. The value objects are > > representative of the > > > object model of your application. The persistence layer, > > implemented by EJBs > > > and/or DAOs, converts between the application object model > > represented by > > > the value objects and the persistence model represented by > > classes that are > > > closely related in structure to your database tables. > > > > > > As I said before, this may seem like overkill to some. And > > it might really > > > be overkill depending on your application and its > > requirements. But I think > > > that this pattern serves to keep the layers of your model decoupled > > > according to a logical separation of concerns. It > > represents, I think, a > > > focus on the business layer being the true heart of the > > system with the > > > presentation and persistence layers there to support it. > > And since the > > > persistence layer is encapsulated from the business and > > presentation layers, > > > you can choose to change out your persistence layer or > > mingle technologies > > > as you see fit. > > > > > > If you'd like to see more, you might visit the J2EE > > patterns catalog here: > > > > > http://developer.java.sun.com/developer/technicalArticles/J2EE > > /patterns/ > > > > > > This material has subsequently been refined and published > > in the Core J2EE > > > Patterns book: http://www.bookpool.com/.x/t4tyn2dfrn/sm/0130648841 > > > > > > Best regards, > > > Jim Cakalic > > > > > > > -----Original Message----- > > > > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] > > > > Sent: Tuesday, February 26, 2002 10:51 AM > > > > To: [EMAIL PROTECTED] > > > > Subject: DB Access from Struts > > > > > > > > > > > > Hello, > > > > > > > > A general practices question about db access using standard > > > > java or EJB with struts. What is the best approach for > > > > pluging db access into the struts framework in each case? For > > > > example, if I'm using torque to generate all the DB access > > > > classes, should I still use the Form Bean classes or its > > > > better to simply have the torque classes extend the > > > > ActionForm interface? Or is it better to access the torque > > > > classes in the Action class? And what about EJB? > > > > > > > > Thanks, any help is much appreciated. > > > > > > > > Bilal > > > > > > > > -- > > > > To unsubscribe, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > For additional commands, e-mail: > > > > <mailto:[EMAIL PROTECTED]> > > > > > > > > > > > > > __________________________________________________ > > Do You Yahoo!? > > Yahoo! Greetings - Send FREE e-cards for every occasion! > > http://greetings.yahoo.com > > > > -- > > To unsubscribe, e-mail: > > <mailto:[EMAIL PROTECTED]> > > For additional commands, e-mail: > > <mailto:[EMAIL PROTECTED]> > > > > <font size="1">Confidentiality Warning: This e-mail contains information intended >only for the use of the individual or entity named above. If the reader of this >e-mail is not the intended recipient or the employee or agent responsible for >delivering it to the intended recipient, any dissemination, publication or copying of >this e-mail is strictly prohibited. The sender does not accept any responsibility for >any loss, disruption or damage to your data or computer system that may occur while >using data contained in, or transmitted with, this e-mail. If you have received >this e-mail in error, please immediately notify us by return e-mail. Thank you. -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
