On 7/12/05, Rick Reumann <[EMAIL PROTECTED]> wrote: > I was just replying to a post about keeping your Actions clean and doing > the business logic in other classes. > > One thing I didn't bring up, though, because I'm not sure how 'best > practice' it is, is the concept of passing your ActionForm and sometimes > the HttpServletRequest off to another class for some processing. I'm > doing that a bit in this app I'm currently working on and I'm liking it.
At the risk of getting scolded by the purists on this list, I confess that I have at times done something similar myself. I typically don't pass the request object on and I don't pass the ActionForm directly either. However, I use a trick where a POJO as a nested data member of a DynaActionForm is passed on to my helper classes. In particular, this one webapp of mine relies on a separate SDK that implements all the business functionality. What I ended up doing was defining a web tier service interface for this SDK. My implementation of the various methods in this service interface takes an input POJO and returns either a single value or an output POJO. A trick that I learned from Matt Raible's AppFuse code was to implement my ActionForms with the DynaActionForm in my struts config file. Typically, my input POJO for a particular service interface method is implemented as a POJO. For example, a logon POJO with username and password getter/setters. The form bean in the struts config for the logon action would have a data member associated with this POJO as a nested data object in the logon form. Then my action code is about 10 lines of code (not counting exception/error handling catch block logic). I get the POJO out of the Struts DynaActionForm in the Logon action and simply pass that in to the service interface method call. Errors are returned via unique Exceptions. So, I can have customized error messages reported back to the user by wrapping the call to the service interface method in my action classes with a try/catch block. With this approach, I still have to write the POJOs, but, they are easy to write. The nice thing is that each piece of the puzzle is simple. The POJOs are simple, the action code is simple, the service interface method implementations are simple. I can write complicated code, but, I firmly believe in keeping it simple. Simpler code is easier to maintain for myself and easier to handoff to other developers to maintain too. This allows me to unit test just my service interface implementation in isolation from the webapp with *NO* Struts dependencies. I also use the Spring container to inject the implementation of the service interface into my action classes when they are instantiated (another technique I picked up from AppFuse). This allows me to test the webapp with *NO* running service layer required. I write a stub implementation of the service interface and use an Ant build property setting to toggle which implementation of the service interface is used in the generated webapp. I have used this approach in a team environment with great success recently. I had a separate UI person clean up the UI by working with the webapp using the stub service interface implementation. They were able to change just about anything in the UI and build/test their stubbed version without being on our engineering development network. Much nicer than getting static HTML thrown over the wall to me to incorporate into the webapp. I believe this is basically an intermediate Value Object (VO) approach. I'm using the POJOs defined as nested elements of the DynaActionForms as VOs. The service interface methods are where the translation is done from VO String properties to the properly typed data in the data structures expected by the actual service I am interacting with for the business logic. Still, this allows me to take advantage of the declarative form data validation provided by Commons Validator in the actions before passing the VOs on to the service interface methods. I'm not saying this is rocket science. I'm sure others have done something similar. I only mention it because I was hesitant to use the VO approach when I first heard about it because it sounded like there would be three data objects required for each operation. The form bean, the value object and then the final business object on top of that. Three objects for each operation seemed a bit much to me. This simple trick allows you to eliminate the form bean class at least. And the separation benefits of having the two objects per operation has definitely paid off in my own development process. -Van -- - Mike "Van" Riper [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
