Page 34 in Core J2EE Patterns 2nd Ed. talks about the problems related to exposing presentation-tier data structures to the business tier. The main problem this poses is that it increases the coupling between the tiers and reduces the reusability of the underlying services. Pages 80-83 discuss some excellent alternatives.
We recently experienced this when we wanted to expose some of our service layer classes as web services. There were some instances where we passed the form object and/or the request object. We had to do some refactoring. Brian Barnett -----Original Message----- From: Rick Reumann [mailto:[EMAIL PROTECTED] Sent: Tuesday, July 12, 2005 9:45 AM To: Struts Users Mailing List Subject: anyone else pass their ActionForm off to another layer 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. Here are my thoughts. Typically I've dones this kind of stuff in my dispatch Action methods.... SomeForm sForm = (SomeForm)form; //some validation now possibly SomeVO vo = new SomeVO(); BeanUtils.copyProperties( vo, form ); service.update( vo ); //save some success message or error message The above is quite simple but sometimes there are some other things that have to be done that aren't alway orthodox... ie, maybe having to build more than one VO from a form, or maybe some logic looking at certain form/request parameters to dictate some slightly altered service class method to call. All of this stuff tends to staring bloat the Action class which is supposed to mainly be a controller. I've started now playing around with pushing some of this off to another class and the Action then becomes mostly just responsible for 1) validation 2) saving any success or error messages 3) fowarding So what happens is the Action looks like... //EmployeeAction execute(...) or dispatchmethod() { EmployeForm empForm = (EmployeeForm)form; //validate form, if success proceed.. boolean success = EmployeeActionHelper.updateEmployee( empForm, request ); //messages set up based on success or failure } The above hides all the mundane copy form properties to vo and any other logic (for example if returning a List you could put that in scope in the Helper). Possibly all of this is overkill, but it came about based on a real use case. The situation is when CRUD operations are selected from the form, the type of Value Object created and the type of Service that gets called is based on a requirement passed in by the form. What gets done when the form is submitted can be very different based on the type of object being represented when the form submits, so I needed a way to get a unique type of Service/Delegate base on the ID. I found it clean to isolate all of this from the Action, so the Action method looks like... update(..) { MyForm myForm = (MyForm)form; ServiceFactory.getService( myForm.getTypeID ).update( myForm ); //other stuff Now since the correct Service is obtained, it can do the copying of proeprties to the unique value object and can call the approrpriate DAO that is in that service class. Anyway, I'm just babbling:) -- Rick --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] **************************************************************************** This email may contain confidential material. If you were not an intended recipient, Please notify the sender and delete all copies. We may monitor email to and from our network. **************************************************************************** --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
