Yes. With the help of decent framework Action and a standard result object, it's not hard to take the command pattern one step farther. This can get all the business tier code out of the Actions. Actions are a great and necessary class, but they are hard to reuse, even within the same application. While it's entirely possible to forward control from one Action another, it ain't pretty. In practice, many operations can be aggregated from smaller operations. A move is a copy and a delete. This is not a lot of fun with Actions, but no sweat at all with a business bean.
-T. "Molitor, Stephen" wrote: > > That was my understanding of Ted's emails. Ted, is this correct? > > This approach would seem to have the usual advantages and disadvantages of > the Command pattern. With the command pattern, you turn what would be > individual methods of one class into separte command classes. Since the > commands are now objects, you can do object oriented things with them, like > inheritance, composition, store them in a list, have a controller that pre > and post processes the command objects. The disadvantage of course is that > you have lots of little classes. > > Steve Molitor > > -----Original Message----- > From: Robert Taylor [mailto:[EMAIL PROTECTED]] > Sent: Thursday, June 06, 2002 2:25 PM > To: Struts Users Mailing List > Subject: RE: [Struts Tips] #2 - Template Method Dispatch Action? > > So if I had an XXXXAction that handled the following operations on an > account: > > -createAccount > -retrieveAccount > -updateAccount > -deleteAccount > > instead of having these 4 methods defined, in a single action class, you > would define a business bean in the action mapping and something similar to > the following operations would take place in sequence when the XXXXAction > was invoked. > > -The XXXXAction class accesses business bean (creates or retrieves). > -The XXXXAction class converts (directly or indirectly) user input into > expected business input arguments . > -The XXXXAction class invokes business bean hotspot method with business > arguments. > -The business bean processes input and performs the appropriate command > logic. > -The business bean returns a business bean return object. > -The XXXXAction class processes the business bean return object to determine > the ActionForward. > -The XXXXAction class returns ActionForward to the web controller. > > So you might end up having business beans/delegates like > CreateAccountCommand, RetrieveAccountCommand, UpdateAccountCommand, and > DeleteAccountCommand, instead of separate XXXXAction classes or a single > XXXXAction class with the four methods. Each of the four business beans > might then delegate to a common business service called something like > IAccountService to handle or delegate processing. > > Did I interpret that correctly? > > robert -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
