To me, the presentation tier's main responsibility is to mediate
between the user and business layer. Validation, forwarding, etc --
that's presentation tier logic that my business tier objects don't
care about (usually). From the business tier's perspective, the meat
is in the conversion between HTTP strings to/from business objects,
and the call to the correct business tier class/method.
In most cases, a simple BeanUtils.copyProperties() (or equivalent)
call is enough to convert between user input and business layer data.
Even if there was more to it than that (multiple objects/types, nested
objects, etc), I still consider that presentation tier conversion. In
your example, I would probably extract multiple sets of data and then
call the business tier object and pass those. I may do the extraction
in the action, or I may use a util class that gets called by the
action, but the point is, the business tier objects only work with
business tier objects:
int someId = // retrieve id from form
MyPojo myPojo = // populate pojo from data in form
myServiceLayerObject.someBusinessProcess(someId,myPojo);
Hubert
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.
>
> 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]
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
