Thanks, Ted, for clarifying these issues for me. > -----Original Message----- > From: Ted Husted [mailto:[EMAIL PROTECTED]] > Sent: Sunday, February 02, 2003 11:06 AM > To: [EMAIL PROTECTED] > Subject: Re: design question about action chaining > > > In Patterns of Enterprise Application Architecture [1], Martin Fowler > [2] lays out two basic patterns for handling business logic [3]. > > * Transaction Script - "Organizes business logic by procedures where > each procedure handles a single request from the presentation. > > * Domain Model - "An object model of the domain that incorporates both > behavior and data." > > The Struts MailReader example uses the Transaction Script > pattern. This > is a fine way to go for simple applications. I used it myself in my > first significant Struts application (an online auction), > still do, and > probably always will. It's simple and efficient, and when the logic is > not complex, does the job quite well, thank you. > > The Artimus example [4] from Struts in Action uses the domain model. > Here a stub Action is used to call a domain object. The domain object > does all of the processing for this transaction and returns a > response. > The stub Action analyzes the domain's response and bundles everything > into a HTTP response. > > The Artimus example is not so complex that it really needs to > use Domain > Model, but I wanted it to contrast the MailReader example. > > My second significant Struts application was a telemarketing and > inventory manager for the first auction application. Here, > the logic is > sometimes quite complex, and I *do* need to use the domain model. > Compared to the public auction application, there's an extra layer of > indirection, but it can do ~whatever~ I need it to do. > > It's my belief that when people start to chain Actions, they > are trying > to move from a Transaction Script to a Domain Model. Problem is, they > are trying to do it with Struts Actions rather than POJO's (Plain Old > Java Objects). > > There are several problems with using Struts Action classes as Domain > Objects: > > * First, you must embed complex business logic inside of a HTTP > presentation tier class. As long you use Struts and nothing > but Struts, > this is not necessarily a problem. But you never know what nutty idea > the suits will have next =:0) > > * Second, the Action interface is not designed so that one Action can > call another. In more complicated applications, use-case "C" > is really a > combination of cases "A" and "B". With Actions, to get to C, > you need to > forward through A and B (hence the "chain"). With POJO, C can cleanly > call A and B and return the result. The presentation tier > doesn't know, > or need to know, that C is a combination of A and B. Such "chains of > responsibility" are the concern of application controllers, but should > not be delegated to a presentation tier controller, like Struts. > > * Third, Struts Test Case [5] makes testing Struts actions relatively > simple, but the tests are still more complicated that testing POJOs > alone. With PODOs (Plain Old Domain Objects), you can have > two layers of > tests: a pure TestCase against the business logic, and a > Struts TestCase > against the interaction between the business layer and the > presentation > layer. > > It's my thinking that you should be able to look at any given > ActionMapping and say "this uses Transaction Script" or "this uses > Domain Model". If you can't, then I would suggest that you may be > letting the tail wag the dog =:0) > > Struts uses a number of very excellent patterns. I am > continually amazed > at how well it all fits together. The trick is to use the > same patterns > in your enterprise architecture. The "dark side" is letting Struts > ~become~ your enterprise architecture. Faster yes, better no. > > -Ted. > > Resources > --------- > > [1] Patterns of Enterprise Application Architecture > <http://www.amazon.com/exec/obidos/ISBN=0321127420 /hitchhikeguidetoA/>
[2] Martin Fowler also wrote "Refactoring", among others. He is definitely one of our favorite ~non-fiction~ authors. [3] Business logic - An oxymoron akin to "military intelligence". Business logic is whatever nutty stuff the client wants to do with the data that we have so carefully obtained, stored, and retrieved (using system logic). Sadly, implementing the business logic is what they actually ~pay~ us to do, rather than the other interesting stuff that we enjoy doing on the way. (The voyage is the reward.) [4] Artimus CVS <http://cvs.sourceforge.net/cgi-bin/viewcvs.cgi/struts/artimus/> [5] My new best friend <http://sourceforge.net/projects/strutstestcase/> -- Ted Husted, Struts in Action <http://husted.com/struts/book.html> --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
