You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Brady Hegberg <br...@bitstream.net> on 2005/07/12 18:37:57 UTC
Handling VOs
Rick sent the example code below to an user earlier and I was just
wondering. Would it be acceptable to generate the EmployeeVO using a
constructor like:
EmployeeVO emp = new EmployeeVO( eForm );
Would that be considered tying the view to the business layer? It seems
like it would work nicely especially since you could use polymorphism if
you needed to generate VOs from other Forms (ie
AnotherEmployeeActionForm).
Thanks,
Brady
> //In Action method:
> execute(...) //or dispatchMethod update(..) {
> //cast to your ActionForm of String properties
> EmployeeActionForm eForm = (EmployeeActionForm)form;
>
> //business POJO with correct Data types
> EmployeeVO emp = new EmployeeVO();
>
> //easy to take the stuff from ActionForm to VO
> BeanUtils.copyProperties( emp, eForm );
>
> //Do the update
> yourEmployeeDAO.updateEmployee( emp );
> }
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Handling VOs
Posted by Larry Meadors <la...@gmail.com>.
On 7/12/05, Brady Hegberg <br...@bitstream.net> wrote:
> So accepted best practice in this case is to have a method in your
> action that transfers the data from the form to the VO, then pass the VO
> off?
IMO, this is sort of a waste if you can do it in the form by adding
the VO to it, and handling it that way (where you have access to all
of the resources).
Larry
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Handling VOs
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Tue, July 12, 2005 1:09 pm, Brady Hegberg said:
> So accepted best practice in this case is to have a method in your
> action that transfers the data from the form to the VO, then pass the VO
> off?
Not usually a separate method, just usually, a single line of code. But
yes, that's the generally-accepted best practice of the day in a nutshell.
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Handling VOs
Posted by Brady Hegberg <br...@bitstream.net>.
And Rick already pointed out reasons it can be a bad idea to pass a map
to a class that extracts the data because you end up with confusion
about fields and lose type checking.
So accepted best practice in this case is to have a method in your
action that transfers the data from the form to the VO, then pass the VO
off?
-Brady
> I would say no, it's no more acceptable (acceptable being a relative term
> of course!).
>
> An EmployeeVO, presuming that is an object passed form the control layer
> to the model layer, still needs to know about something in the view layer,
> the ActionForm. Hence, it's not really any better.
>
> In reply to Rick's original post, I echo the thoughts of others that
> passing an ActionForm out of an Action to a delegate is generally a bad
> idea, and certainly is not in keeping with the original intent of an
> ActionForm, nor in what are generally seen as the best practices of the
> time.
>
> Passing the request is kind of a separate question, but just as
> undesirable in my opinion because it ties your model to the presentation
> mechanism. What if someone comes along and wants to take your web-based
> application and create a Swing front-end for it?
>
> Another good reason to not pass request around is that your business
> delegates become harder to unit test because now you have to deal with
> mock request objects, or maybe even a whole mock servlet setup (I've seen
> session passed to business delegates too).
>
> I believe Rick knows when he is breaking the "rules" and consciously
> chooses to do so :) That's acceptable because he understands the
> consequences and can intelligently make the decision. It's important
> though that new developers understand not only what things are frowned
> upon, but also WHY they are frowned upon. I can speak from experience
> when I say I haven't always followed best practices, sometimes because the
> situation warranted, but also sometimes because I didn't understand the
> reasoning behind the practices and hence wasn't convinced to follow them.
> Best practices are best practices because people tend to agree they have
> more benefit than other approaches in most cases, and that is the case
> here.
>
--
Brady Hegberg <br...@bitstream.net>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Handling VOs
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
On Tue, July 12, 2005 1:08 pm, Larry Meadors said:
> I still do not see why putting your VO on your action form is a bad thing.
>
> 1) It gives you a super-easy way to map strings (bean.propName)
I guess I'm not clear on this... are you talking about nesting the VO in
the ActionForm, or are you talking about having the properties that would
otherwise be in the VO be in the ActionForm?
> 2) It gives you an easy way to perform string->type conversions
How does it make it any easier than if they are separate objects?
> 3) It does not couple your VO to your form
Again, not clear on this... whether the VO is nested in the form or the
form just contains the VO properties, how is that not coupled?
> 4) While it does couple your form to your VO, who cares?
Isn't this directly contradicting #3? :)
Generally-speaking, any time someone says "who cares" about an
architectural decision, I've found that usually means they understand what
they are doing might not be a good decision long-term, but go with it
anyway because its easier short-term. And I've done it myself too, so I
don't say this from a position of superiority or anything.
It's the long-term that will bite you, not the short-term, so its more
important to make decisions that will seem right a year down the road, to
the extent that is ever possible in this field, IMO.
> 5) When your Action gets the form, it also has the VO, with strongly
> typed and named values ready to go to the business tier.
How does it already have these values? Could you explain your approach a
bit more?
Frank
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Handling VOs
Posted by Larry Meadors <la...@gmail.com>.
I still do not see why putting your VO on your action form is a bad thing.
1) It gives you a super-easy way to map strings (bean.propName)
2) It gives you an easy way to perform string->type conversions
3) It does not couple your VO to your form
4) While it does couple your form to your VO, who cares?
5) When your Action gets the form, it also has the VO, with strongly
typed and named values ready to go to the business tier.
So, what is the down side?
Larry
On 7/12/05, Frank W. Zammetti <fz...@omnytex.com> wrote:
> I would say no, it's no more acceptable (acceptable being a relative term
> of course!).
>
> An EmployeeVO, presuming that is an object passed form the control layer
> to the model layer, still needs to know about something in the view layer,
> the ActionForm. Hence, it's not really any better.
>
> In reply to Rick's original post, I echo the thoughts of others that
> passing an ActionForm out of an Action to a delegate is generally a bad
> idea, and certainly is not in keeping with the original intent of an
> ActionForm, nor in what are generally seen as the best practices of the
> time.
>
> Passing the request is kind of a separate question, but just as
> undesirable in my opinion because it ties your model to the presentation
> mechanism. What if someone comes along and wants to take your web-based
> application and create a Swing front-end for it?
>
> Another good reason to not pass request around is that your business
> delegates become harder to unit test because now you have to deal with
> mock request objects, or maybe even a whole mock servlet setup (I've seen
> session passed to business delegates too).
>
> I believe Rick knows when he is breaking the "rules" and consciously
> chooses to do so :) That's acceptable because he understands the
> consequences and can intelligently make the decision. It's important
> though that new developers understand not only what things are frowned
> upon, but also WHY they are frowned upon. I can speak from experience
> when I say I haven't always followed best practices, sometimes because the
> situation warranted, but also sometimes because I didn't understand the
> reasoning behind the practices and hence wasn't convinced to follow them.
> Best practices are best practices because people tend to agree they have
> more benefit than other approaches in most cases, and that is the case
> here.
>
> --
> Frank W. Zammetti
> Founder and Chief Software Architect
> Omnytex Technologies
> http://www.omnytex.com
>
> On Tue, July 12, 2005 12:37 pm, Brady Hegberg said:
> > Rick sent the example code below to an user earlier and I was just
> > wondering. Would it be acceptable to generate the EmployeeVO using a
> > constructor like:
> >
> > EmployeeVO emp = new EmployeeVO( eForm );
> >
> > Would that be considered tying the view to the business layer? It seems
> > like it would work nicely especially since you could use polymorphism if
> > you needed to generate VOs from other Forms (ie
> > AnotherEmployeeActionForm).
> >
> > Thanks,
> > Brady
> >
> >> //In Action method:
> >> execute(...) //or dispatchMethod update(..) {
> >> //cast to your ActionForm of String properties
> >> EmployeeActionForm eForm = (EmployeeActionForm)form;
> >>
> >> //business POJO with correct Data types
> >> EmployeeVO emp = new EmployeeVO();
> >>
> >> //easy to take the stuff from ActionForm to VO
> >> BeanUtils.copyProperties( emp, eForm );
> >>
> >> //Do the update
> >> yourEmployeeDAO.updateEmployee( emp );
> >> }
> >
> >
> > ---------------------------------------------------------------------
> > To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> > For additional commands, e-mail: user-help@struts.apache.org
> >
> >
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Handling VOs
Posted by "Frank W. Zammetti" <fz...@omnytex.com>.
I would say no, it's no more acceptable (acceptable being a relative term
of course!).
An EmployeeVO, presuming that is an object passed form the control layer
to the model layer, still needs to know about something in the view layer,
the ActionForm. Hence, it's not really any better.
In reply to Rick's original post, I echo the thoughts of others that
passing an ActionForm out of an Action to a delegate is generally a bad
idea, and certainly is not in keeping with the original intent of an
ActionForm, nor in what are generally seen as the best practices of the
time.
Passing the request is kind of a separate question, but just as
undesirable in my opinion because it ties your model to the presentation
mechanism. What if someone comes along and wants to take your web-based
application and create a Swing front-end for it?
Another good reason to not pass request around is that your business
delegates become harder to unit test because now you have to deal with
mock request objects, or maybe even a whole mock servlet setup (I've seen
session passed to business delegates too).
I believe Rick knows when he is breaking the "rules" and consciously
chooses to do so :) That's acceptable because he understands the
consequences and can intelligently make the decision. It's important
though that new developers understand not only what things are frowned
upon, but also WHY they are frowned upon. I can speak from experience
when I say I haven't always followed best practices, sometimes because the
situation warranted, but also sometimes because I didn't understand the
reasoning behind the practices and hence wasn't convinced to follow them.
Best practices are best practices because people tend to agree they have
more benefit than other approaches in most cases, and that is the case
here.
--
Frank W. Zammetti
Founder and Chief Software Architect
Omnytex Technologies
http://www.omnytex.com
On Tue, July 12, 2005 12:37 pm, Brady Hegberg said:
> Rick sent the example code below to an user earlier and I was just
> wondering. Would it be acceptable to generate the EmployeeVO using a
> constructor like:
>
> EmployeeVO emp = new EmployeeVO( eForm );
>
> Would that be considered tying the view to the business layer? It seems
> like it would work nicely especially since you could use polymorphism if
> you needed to generate VOs from other Forms (ie
> AnotherEmployeeActionForm).
>
> Thanks,
> Brady
>
>> //In Action method:
>> execute(...) //or dispatchMethod update(..) {
>> //cast to your ActionForm of String properties
>> EmployeeActionForm eForm = (EmployeeActionForm)form;
>>
>> //business POJO with correct Data types
>> EmployeeVO emp = new EmployeeVO();
>>
>> //easy to take the stuff from ActionForm to VO
>> BeanUtils.copyProperties( emp, eForm );
>>
>> //Do the update
>> yourEmployeeDAO.updateEmployee( emp );
>> }
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Handling VOs
Posted by Dave Newton <ne...@pingsite.com>.
Dave Newton wrote:
> Brady Hegberg wrote:
>
>> EmployeeVO emp = new EmployeeVO( eForm );
>>
>> Would that be considered tying the view to the business layer? It seems
>> like it would work nicely especially since you could use polymorphism if
>> you needed to generate VOs from other Forms (ie
>> AnotherEmployeeActionForm).
>>
>>
> Yep, that ties the layers together because the
Uh...
Because the EmployeeVO must know how to construct itself with something
from the Struts framework.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org
Re: Handling VOs
Posted by Dave Newton <ne...@pingsite.com>.
Brady Hegberg wrote:
>EmployeeVO emp = new EmployeeVO( eForm );
>
>Would that be considered tying the view to the business layer? It seems
>like it would work nicely especially since you could use polymorphism if
>you needed to generate VOs from other Forms (ie
>AnotherEmployeeActionForm).
>
>
Yep, that ties the layers together because the
Generally I'll create utility classes with factory methods to construct
things that cross layers.
Dave
---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org