You are viewing a plain text version of this content. The canonical link for it is here.
Posted to user@struts.apache.org by Jordan Reed <jo...@hotmail.com> on 2003/05/29 06:28:40 UTC
Populating Value Objects for the Business Tier
All,
I'm on a team that's trying to decided on a best practice for passing on
populating our value objects that get passed to our business layer. We
currently have three techniques we've though up and I'm wonderful if anyone
has a strong opinion on which one may be the "best" and why.
The basic problem is that the user enters information into a form. The form
is a presentation object, and should not be passed to the business layer.
So it's information needs to be in a presentation-agnostic interface before
being passed to the data layer.
1) Have the action class copy information from the form to a value object.
Have a view helper copy information from the value object into the form (for
pre-population)
2) Have the form implement a value-object-like interface. The business
layer accepts objects with these business interfaces. This way it is
possible to pass the form objects to the business layer without the business
layer knowing that they are presentation objects.
3) Have the form simply include value objects as properties. Then use the
nested taglibs to populate the value objects. This way the Action can just
pull the value object off directly and pass to the business layer. A view
helper can just set the value object on the form.
-jdr
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Populating Value Objects for the Business Tier
Posted by Ted Husted <hu...@apache.org>.
Any and all of these are best practices. Practices are like patterns.
Which is "best" for your depends on your circumstances. It's not
something anyone else can decide for you.
Quite a bit depends on what you do on the business layer. An application
needs to cater to the business layer, and each of the practices work
better or worse with different business layer implementations.
**Pick a use-case and try all three for yourself**, and then pick the
one that you feel works best for your team and your business layer.
But as others have mentioned,
(1) is the most flexible and is usually the generic starting point, but
it can require the most code and most data transfers. But it is the
single, best way to insulate the presentation layer from the business
layer.
(2) works well if-and-only-if your business layer understands that it
*is* a business layer and is designed to play well with other layers.
This can require the least code and fewest data transfers, but *only* if
the business layer is designed to be a team player. (Many aren't.)
(3) can be the quickest way to deploy an application, but the slowest
way to grow an application. If the value objects change, you need to
change your pages to reflect the change. With the other approaches, you
can make the changes in the Java code (often in a single location),
without changing the pages.
Sometimes you can merge (2) and (3). The value-object interface is a
facade. It exposes flat properties, like customerAddress, but underneath
implements properties as customer.address(). So, you end up passing the
data-entry facade to the business-logic facade. But, again, this is not
a good match for every facade.
-Ted.
Jordan Reed wrote:
> All,
>
> I'm on a team that's trying to decided on a best practice for passing on
> populating our value objects that get passed to our business layer. We
> currently have three techniques we've though up and I'm wonderful if anyone
> has a strong opinion on which one may be the "best" and why.
>
> The basic problem is that the user enters information into a form. The form
> is a presentation object, and should not be passed to the business layer.
> So it's information needs to be in a presentation-agnostic interface before
> being passed to the data layer.
>
> 1) Have the action class copy information from the form to a value object.
> Have a view helper copy information from the value object into the form (for
> pre-population)
>
> 2) Have the form implement a value-object-like interface. The business
> layer accepts objects with these business interfaces. This way it is
> possible to pass the form objects to the business layer without the business
> layer knowing that they are presentation objects.
>
> 3) Have the form simply include value objects as properties. Then use the
> nested taglibs to populate the value objects. This way the Action can just
> pull the value object off directly and pass to the business layer. A view
> helper can just set the value object on the form.
>
>
> -jdr
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Populating Value Objects for the Business Tier
Posted by Vic Cekvenich <vc...@baseBeans.com>.
+ 0 Mike.
I show the methods 1-3 when I teach and in my 2nd Struts book.
Then I teach formBean has a DAO helper (is a/has a)
In action you just say:
formBean.populate(req.getParm);
And then in baseFormBean:
populate(Object o) {
myDao.populate(XX); // populate DAO from DB
_list = myDao.getData(); // copy data from DAO to formBean.
}
This way you can reuse your layers. (So you have nice noun.verb();)
I can now unit test Model (MVC layers benefit is that I can unit test a
component), use in JSTL, re-use in Model 1, javascript, console apps
(for asyn. acces).
All the action should be used is to decide where to go to next based on
(error?) conditions.
.V
Mike Duffy wrote:
>I would suggest option 1, with a slight variation.
>
>I think it is best to keep action classes as lean as possible.
>Rather than doing any heavy lifting in an action class it is better
>to make calls to delegates and other helper classes. The modular
>nature of the code enhances code reuse and maintainability. Also,
>the system becomes more flexible.
>
>With this said, rather than "Have the action class copy information
>from the form to a value object.", IMHO it is better to make a call
>to a method in a factory class that takes in an action form and
>returns a value object.
>
>Within the factory method, I would highly recommend use of the method
>BeanUtils.copyProperties(java.lang.Object dest, java.lang.Object
>orig)
>
>You may be able to use the copyProperties method to completely copy
>your action form to value object, but in all but the most simple
>cases you will probably need to do some additional massaging based on
>selections made in the web interface.
>
>As a simple example, if you have a web interface for user
>registration with a corresponding UserActionForm and UserValueObject,
>you would pass an instance of the UserActionForm to the method
>createFromActionForm in the UserFactory class. This method would
>return a UserValueObject which could then be passed to a DAO object
>for persistence.
>
>The UserFactory might also have other create methods that would
>create users from sources other than a web interface (comma delimited
>text file, etc.).
>
>In this simple example, it might seem like overkill to create a
>factory class to process a simple user form; however, as an
>application becomes more complex keeping to a design pattern that
>everyone uses truly enhances the quality of life (IMHO this is the
>greatest advantage of Struts; an advantage not easily seen in simple
>systems, but readily apparent in complex systems.).
>
>A more complex example would be the processing of energy data from a
>web interface and from several several different corporations and
>state agencies. The factory classes are the focal point for creating
>value objects from different resources.
>
>Mike
>
>--- Andrew Hill <an...@gridnode.com> wrote:
>
>
>>2 & 3 generally end in tears. They sound nice, but when you get
>>down to the
>>fiddly bits you will find it more problematic than you expect.
>>
>>As you mention, the action form is very much a view object. For a
>>start
>>everything in the actionForm will be strings, while your business
>>object
>>probably will not be. Secondly, while there is considerable overlap
>>between
>>your value object and your form, you will find (especially as your
>>ui gets
>>more complex) that the correlation is not 1 to 1 and that you are
>>exerting a
>>lot of effort to try and keep the two the same.
>>
>>Approach 3 is probably the worst - unless its for read only display
>>- in
>>that if the user enters a value that doesnt convert to your value
>>objects
>>property type you will want to redisplay the offending value string
>>the same
>>as the user typed it for them to correct it.
>>
>>Your best bet is to use approach 1. You may be interested to note
>>that the
>>BeanUtils class does have some methods that can make life simpler
>>for you -
>>copying property values and doing type conversions automatically
>>(if I
>>recall correctly).
>>
>>(Actually I generally copy the properties the 'hard' way, one by
>>one in my
>>action)
>>
>>-----Original Message-----
>>From: Jordan Reed [mailto:jordan_d_reed@hotmail.com]
>>Sent: Thursday, 29 May 2003 12:29
>>To: Struts Users Mailing List
>>Subject: Populating Value Objects for the Business Tier
>>
>>
>>All,
>>
>>I'm on a team that's trying to decided on a best practice for
>>passing on
>>populating our value objects that get passed to our business layer.
>> We
>>currently have three techniques we've though up and I'm wonderful
>>if anyone
>>has a strong opinion on which one may be the "best" and why.
>>
>>The basic problem is that the user enters information into a form.
>>The form
>>is a presentation object, and should not be passed to the business
>>layer.
>>So it's information needs to be in a presentation-agnostic
>>interface before
>>being passed to the data layer.
>>
>>1) Have the action class copy information from the form to a value
>>object.
>>Have a view helper copy information from the value object into the
>>form (for
>>pre-population)
>>
>>2) Have the form implement a value-object-like interface. The
>>business
>>layer accepts objects with these business interfaces. This way it
>>is
>>possible to pass the form objects to the business layer without the
>>business
>>layer knowing that they are presentation objects.
>>
>>3) Have the form simply include value objects as properties. Then
>>use the
>>nested taglibs to populate the value objects. This way the Action
>>can just
>>pull the value object off directly and pass to the business layer.
>>A view
>>helper can just set the value object on the form.
>>
>>
>>-jdr
>>
>>
>>
>>
>>
>---------------------------------------------------------------------
>
>
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail:
>>struts-user-help@jakarta.apache.org
>>
>>
>>
>>
>>
>---------------------------------------------------------------------
>
>
>>To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
>>For additional commands, e-mail:
>>struts-user-help@jakarta.apache.org
>>
>>
>>
>
>__________________________________
>Do you Yahoo!?
>Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
>http://calendar.yahoo.com
>
>
--
Vic Cekvenich,
Struts Instructor,
1-800-917-JAVA
Advanced <a href ="baseBeans.com">Struts Training</a> and project recovery in North East.
Open Source <a href ="baseBeans.com">Content Management</a> basicPortal sofware
Best practice<a href ="baseBeans.com">Struts Support</a> v.1.1 helper ScafflodingXPress
RE: Populating Value Objects for the Business Tier
Posted by Steve Raeburn <st...@ninsky.com>.
ActionForms should carry a Strings only health advisory ;-)
Steve
> -----Original Message-----
> From: Jordan Reed [mailto:jordan_d_reed@hotmail.com]
> Sent: May 30, 2003 11:04 AM
> To: Struts Users Mailing List
> Subject: Re: Populating Value Objects for the Business Tier
>
>
> I've been playing #3 (Just included the value objects in the form) and run
> into one of those things that probably makes people break into tears.
>
> I have int types in the value object... And since they cannot be
> null, when
> the form is prepopulated or repopulated they appear as "0"
> instead of being
> blank or what the user entered. Sad.
>
> -jdr
>
> On 5/28/03 9:53 PM, "Andrew Hill" <an...@gridnode.com> wrote:
>
> > 2 & 3 generally end in tears. They sound nice, but when you get
> down to the
> > fiddly bits you will find it more problematic than you expect.
> >
> > As you mention, the action form is very much a view object. For a start
> > everything in the actionForm will be strings, while your business object
> > probably will not be. Secondly, while there is considerable
> overlap between
> > your value object and your form, you will find (especially as
> your ui gets
> > more complex) that the correlation is not 1 to 1 and that you
> are exerting a
> > lot of effort to try and keep the two the same.
> >
> > Approach 3 is probably the worst - unless its for read only display - in
> > that if the user enters a value that doesnt convert to your
> value objects
> > property type you will want to redisplay the offending value
> string the same
> > as the user typed it for them to correct it.
> >
> > Your best bet is to use approach 1. You may be interested to
> note that the
> > BeanUtils class does have some methods that can make life
> simpler for you -
> > copying property values and doing type conversions automatically (if I
> > recall correctly).
> >
> > (Actually I generally copy the properties the 'hard' way, one
> by one in my
> > action)
> >
> > -----Original Message-----
> > From: Jordan Reed [mailto:jordan_d_reed@hotmail.com]
> > Sent: Thursday, 29 May 2003 12:29
> > To: Struts Users Mailing List
> > Subject: Populating Value Objects for the Business Tier
> >
> >
> > All,
> >
> > I'm on a team that's trying to decided on a best practice for passing on
> > populating our value objects that get passed to our business layer. We
> > currently have three techniques we've though up and I'm
> wonderful if anyone
> > has a strong opinion on which one may be the "best" and why.
> >
> > The basic problem is that the user enters information into a
> form. The form
> > is a presentation object, and should not be passed to the
> business layer.
> > So it's information needs to be in a presentation-agnostic
> interface before
> > being passed to the data layer.
> >
> > 1) Have the action class copy information from the form to a
> value object.
> > Have a view helper copy information from the value object into
> the form (for
> > pre-population)
> >
> > 2) Have the form implement a value-object-like interface. The business
> > layer accepts objects with these business interfaces. This way it is
> > possible to pass the form objects to the business layer without
> the business
> > layer knowing that they are presentation objects.
> >
> > 3) Have the form simply include value objects as properties.
> Then use the
> > nested taglibs to populate the value objects. This way the
> Action can just
> > pull the value object off directly and pass to the business
> layer. A view
> > helper can just set the value object on the form.
> >
> >
> > -jdr
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Populating Value Objects for the Business Tier
Posted by p <ll...@dowman.net>.
Plus you have security issues, it is simple to spoof the form
submission and set properties other than the ones that correspond to
form fields (that is, if there are any other properties on your value
object).
I copy properties using BeanUtils where possible, and for cases where
that doesn't work (there are many) I do it manually in the Action.
The cases where BeanUtils.copyProperties() doesn't work are when the
business object has nested properties, or where the type of the
property is not one of the native types. If anybody has a nice solution
to these I'd like to hear it... I've been thinking about extending
BeanUtils to understand my ObjectID class, java.util.Date, etc.
On Friday, May 30, 2003, at 02:04 PM, Jordan Reed wrote:
> I've been playing #3 (Just included the value objects in the form) and
> run
> into one of those things that probably makes people break into tears.
>
> I have int types in the value object... And since they cannot be null,
> when
> the form is prepopulated or repopulated they appear as "0" instead of
> being
> blank or what the user entered. Sad.
>
> -jdr
>
> On 5/28/03 9:53 PM, "Andrew Hill" <an...@gridnode.com>
> wrote:
>
>> 2 & 3 generally end in tears. They sound nice, but when you get down
>> to the
>> fiddly bits you will find it more problematic than you expect.
>>
>> As you mention, the action form is very much a view object. For a
>> start
>> everything in the actionForm will be strings, while your business
>> object
>> probably will not be. Secondly, while there is considerable overlap
>> between
>> your value object and your form, you will find (especially as your ui
>> gets
>> more complex) that the correlation is not 1 to 1 and that you are
>> exerting a
>> lot of effort to try and keep the two the same.
>>
>> Approach 3 is probably the worst - unless its for read only display -
>> in
>> that if the user enters a value that doesnt convert to your value
>> objects
>> property type you will want to redisplay the offending value string
>> the same
>> as the user typed it for them to correct it.
>>
>> Your best bet is to use approach 1. You may be interested to note
>> that the
>> BeanUtils class does have some methods that can make life simpler for
>> you -
>> copying property values and doing type conversions automatically (if I
>> recall correctly).
>>
>> (Actually I generally copy the properties the 'hard' way, one by one
>> in my
>> action)
>>
>> -----Original Message-----
>> From: Jordan Reed [mailto:jordan_d_reed@hotmail.com]
>> Sent: Thursday, 29 May 2003 12:29
>> To: Struts Users Mailing List
>> Subject: Populating Value Objects for the Business Tier
>>
>>
>> All,
>>
>> I'm on a team that's trying to decided on a best practice for passing
>> on
>> populating our value objects that get passed to our business layer.
>> We
>> currently have three techniques we've though up and I'm wonderful if
>> anyone
>> has a strong opinion on which one may be the "best" and why.
>>
>> The basic problem is that the user enters information into a form.
>> The form
>> is a presentation object, and should not be passed to the business
>> layer.
>> So it's information needs to be in a presentation-agnostic interface
>> before
>> being passed to the data layer.
>>
>> 1) Have the action class copy information from the form to a value
>> object.
>> Have a view helper copy information from the value object into the
>> form (for
>> pre-population)
>>
>> 2) Have the form implement a value-object-like interface. The
>> business
>> layer accepts objects with these business interfaces. This way it is
>> possible to pass the form objects to the business layer without the
>> business
>> layer knowing that they are presentation objects.
>>
>> 3) Have the form simply include value objects as properties. Then
>> use the
>> nested taglibs to populate the value objects. This way the Action
>> can just
>> pull the value object off directly and pass to the business layer. A
>> view
>> helper can just set the value object on the form.
>>
>>
>> -jdr
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail: struts-user-help@jakarta.apache.org
>
>
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Populating Value Objects for the Business Tier
Posted by Jordan Reed <jo...@hotmail.com>.
I've been playing #3 (Just included the value objects in the form) and run
into one of those things that probably makes people break into tears.
I have int types in the value object... And since they cannot be null, when
the form is prepopulated or repopulated they appear as "0" instead of being
blank or what the user entered. Sad.
-jdr
On 5/28/03 9:53 PM, "Andrew Hill" <an...@gridnode.com> wrote:
> 2 & 3 generally end in tears. They sound nice, but when you get down to the
> fiddly bits you will find it more problematic than you expect.
>
> As you mention, the action form is very much a view object. For a start
> everything in the actionForm will be strings, while your business object
> probably will not be. Secondly, while there is considerable overlap between
> your value object and your form, you will find (especially as your ui gets
> more complex) that the correlation is not 1 to 1 and that you are exerting a
> lot of effort to try and keep the two the same.
>
> Approach 3 is probably the worst - unless its for read only display - in
> that if the user enters a value that doesnt convert to your value objects
> property type you will want to redisplay the offending value string the same
> as the user typed it for them to correct it.
>
> Your best bet is to use approach 1. You may be interested to note that the
> BeanUtils class does have some methods that can make life simpler for you -
> copying property values and doing type conversions automatically (if I
> recall correctly).
>
> (Actually I generally copy the properties the 'hard' way, one by one in my
> action)
>
> -----Original Message-----
> From: Jordan Reed [mailto:jordan_d_reed@hotmail.com]
> Sent: Thursday, 29 May 2003 12:29
> To: Struts Users Mailing List
> Subject: Populating Value Objects for the Business Tier
>
>
> All,
>
> I'm on a team that's trying to decided on a best practice for passing on
> populating our value objects that get passed to our business layer. We
> currently have three techniques we've though up and I'm wonderful if anyone
> has a strong opinion on which one may be the "best" and why.
>
> The basic problem is that the user enters information into a form. The form
> is a presentation object, and should not be passed to the business layer.
> So it's information needs to be in a presentation-agnostic interface before
> being passed to the data layer.
>
> 1) Have the action class copy information from the form to a value object.
> Have a view helper copy information from the value object into the form (for
> pre-population)
>
> 2) Have the form implement a value-object-like interface. The business
> layer accepts objects with these business interfaces. This way it is
> possible to pass the form objects to the business layer without the business
> layer knowing that they are presentation objects.
>
> 3) Have the form simply include value objects as properties. Then use the
> nested taglibs to populate the value objects. This way the Action can just
> pull the value object off directly and pass to the business layer. A view
> helper can just set the value object on the form.
>
>
> -jdr
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Populating Value Objects for the Business Tier
Posted by Mike Duffy <md...@yahoo.com>.
I would suggest option 1, with a slight variation.
I think it is best to keep action classes as lean as possible.
Rather than doing any heavy lifting in an action class it is better
to make calls to delegates and other helper classes. The modular
nature of the code enhances code reuse and maintainability. Also,
the system becomes more flexible.
With this said, rather than "Have the action class copy information
from the form to a value object.", IMHO it is better to make a call
to a method in a factory class that takes in an action form and
returns a value object.
Within the factory method, I would highly recommend use of the method
BeanUtils.copyProperties(java.lang.Object dest, java.lang.Object
orig)
You may be able to use the copyProperties method to completely copy
your action form to value object, but in all but the most simple
cases you will probably need to do some additional massaging based on
selections made in the web interface.
As a simple example, if you have a web interface for user
registration with a corresponding UserActionForm and UserValueObject,
you would pass an instance of the UserActionForm to the method
createFromActionForm in the UserFactory class. This method would
return a UserValueObject which could then be passed to a DAO object
for persistence.
The UserFactory might also have other create methods that would
create users from sources other than a web interface (comma delimited
text file, etc.).
In this simple example, it might seem like overkill to create a
factory class to process a simple user form; however, as an
application becomes more complex keeping to a design pattern that
everyone uses truly enhances the quality of life (IMHO this is the
greatest advantage of Struts; an advantage not easily seen in simple
systems, but readily apparent in complex systems.).
A more complex example would be the processing of energy data from a
web interface and from several several different corporations and
state agencies. The factory classes are the focal point for creating
value objects from different resources.
Mike
--- Andrew Hill <an...@gridnode.com> wrote:
> 2 & 3 generally end in tears. They sound nice, but when you get
> down to the
> fiddly bits you will find it more problematic than you expect.
>
> As you mention, the action form is very much a view object. For a
> start
> everything in the actionForm will be strings, while your business
> object
> probably will not be. Secondly, while there is considerable overlap
> between
> your value object and your form, you will find (especially as your
> ui gets
> more complex) that the correlation is not 1 to 1 and that you are
> exerting a
> lot of effort to try and keep the two the same.
>
> Approach 3 is probably the worst - unless its for read only display
> - in
> that if the user enters a value that doesnt convert to your value
> objects
> property type you will want to redisplay the offending value string
> the same
> as the user typed it for them to correct it.
>
> Your best bet is to use approach 1. You may be interested to note
> that the
> BeanUtils class does have some methods that can make life simpler
> for you -
> copying property values and doing type conversions automatically
> (if I
> recall correctly).
>
> (Actually I generally copy the properties the 'hard' way, one by
> one in my
> action)
>
> -----Original Message-----
> From: Jordan Reed [mailto:jordan_d_reed@hotmail.com]
> Sent: Thursday, 29 May 2003 12:29
> To: Struts Users Mailing List
> Subject: Populating Value Objects for the Business Tier
>
>
> All,
>
> I'm on a team that's trying to decided on a best practice for
> passing on
> populating our value objects that get passed to our business layer.
> We
> currently have three techniques we've though up and I'm wonderful
> if anyone
> has a strong opinion on which one may be the "best" and why.
>
> The basic problem is that the user enters information into a form.
> The form
> is a presentation object, and should not be passed to the business
> layer.
> So it's information needs to be in a presentation-agnostic
> interface before
> being passed to the data layer.
>
> 1) Have the action class copy information from the form to a value
> object.
> Have a view helper copy information from the value object into the
> form (for
> pre-population)
>
> 2) Have the form implement a value-object-like interface. The
> business
> layer accepts objects with these business interfaces. This way it
> is
> possible to pass the form objects to the business layer without the
> business
> layer knowing that they are presentation objects.
>
> 3) Have the form simply include value objects as properties. Then
> use the
> nested taglibs to populate the value objects. This way the Action
> can just
> pull the value object off directly and pass to the business layer.
> A view
> helper can just set the value object on the form.
>
>
> -jdr
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
>
__________________________________
Do you Yahoo!?
Yahoo! Calendar - Free online calendar with sync to Outlook(TM).
http://calendar.yahoo.com
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
RE: Populating Value Objects for the Business Tier
Posted by Andrew Hill <an...@gridnode.com>.
2 & 3 generally end in tears. They sound nice, but when you get down to the
fiddly bits you will find it more problematic than you expect.
As you mention, the action form is very much a view object. For a start
everything in the actionForm will be strings, while your business object
probably will not be. Secondly, while there is considerable overlap between
your value object and your form, you will find (especially as your ui gets
more complex) that the correlation is not 1 to 1 and that you are exerting a
lot of effort to try and keep the two the same.
Approach 3 is probably the worst - unless its for read only display - in
that if the user enters a value that doesnt convert to your value objects
property type you will want to redisplay the offending value string the same
as the user typed it for them to correct it.
Your best bet is to use approach 1. You may be interested to note that the
BeanUtils class does have some methods that can make life simpler for you -
copying property values and doing type conversions automatically (if I
recall correctly).
(Actually I generally copy the properties the 'hard' way, one by one in my
action)
-----Original Message-----
From: Jordan Reed [mailto:jordan_d_reed@hotmail.com]
Sent: Thursday, 29 May 2003 12:29
To: Struts Users Mailing List
Subject: Populating Value Objects for the Business Tier
All,
I'm on a team that's trying to decided on a best practice for passing on
populating our value objects that get passed to our business layer. We
currently have three techniques we've though up and I'm wonderful if anyone
has a strong opinion on which one may be the "best" and why.
The basic problem is that the user enters information into a form. The form
is a presentation object, and should not be passed to the business layer.
So it's information needs to be in a presentation-agnostic interface before
being passed to the data layer.
1) Have the action class copy information from the form to a value object.
Have a view helper copy information from the value object into the form (for
pre-population)
2) Have the form implement a value-object-like interface. The business
layer accepts objects with these business interfaces. This way it is
possible to pass the form objects to the business layer without the business
layer knowing that they are presentation objects.
3) Have the form simply include value objects as properties. Then use the
nested taglibs to populate the value objects. This way the Action can just
pull the value object off directly and pass to the business layer. A view
helper can just set the value object on the form.
-jdr
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Populating Value Objects for the Business Tier
Posted by guo yingshou <gu...@yahoo.com.cn>.
I prefer the 3rd choise. As far as I known, it's the
recommended struts-way to go. One of the reasin is
that your bussiness logic is framework independent. In
case you need another kind of client instead of
browser or your boss like something other than
STRUTS,what should you do to your exisiting work?
--- Jordan Reed <jo...@hotmail.com> 的正文：>
All,
>
> I'm on a team that's trying to decided on a best
> practice for passing on
> populating our value objects that get passed to our
> business layer. We
> currently have three techniques we've though up and
> I'm wonderful if anyone
> has a strong opinion on which one may be the "best"
> and why.
>
> The basic problem is that the user enters
> information into a form. The form
> is a presentation object, and should not be passed
> to the business layer.
> So it's information needs to be in a
> presentation-agnostic interface before
> being passed to the data layer.
>
> 1) Have the action class copy information from the
> form to a value object.
> Have a view helper copy information from the value
> object into the form (for
> pre-population)
>
> 2) Have the form implement a value-object-like
> interface. The business
> layer accepts objects with these business
> interfaces. This way it is
> possible to pass the form objects to the business
> layer without the business
> layer knowing that they are presentation objects.
>
> 3) Have the form simply include value objects as
> properties. Then use the
> nested taglibs to populate the value objects. This
> way the Action can just
> pull the value object off directly and pass to the
> business layer. A view
> helper can just set the value object on the form.
>
>
> -jdr
>
>
>
---------------------------------------------------------------------
> To unsubscribe, e-mail:
> struts-user-unsubscribe@jakarta.apache.org
> For additional commands, e-mail:
> struts-user-help@jakarta.apache.org
>
_________________________________________________________
Do You Yahoo!?
流连网络世界的“你”是谁？
http://cn.rd.yahoo.com/mail_cn/tag/?http://cn.surveys.yahoo.com/cn_user_profile_study_may2003
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Populating Value Objects for the Business Tier
Posted by Vic Cekvenich <vc...@baseBeans.com>.
Here is a draft, somone edit and put in Wiki:
Tiers
(To page) There are several approaches to populating DAO (data access
objects) that get the data results from database to eventually populate
the formBean.
(From page) Then the formBean has to have be able to go back to the DAO
for it to populate the DB.
Some approaches work with JSTL others do not.
Some approaches work with multiple rows, others use a different set of
getters/setters or bean.
Some approaches are criticize by Architects: Ex: Rod Johnston
Some approaches are easier to unit tests than others.
Here are the approaches listed:
A
(To page) Have a helper class copy from VO to formBean.
(From page) Action copies via helper factory formBean to VO.
B. formBean implements VO.
(To page) BO populate VOfB
(From page). Action passes VofB to BO.
C. formBean has VO facade as property with getter/setter for VO for use
by nested tags to decode.
Also VO has getters/setter for property.
(To page) Action passes VO from BO to formBean.
(From page) Action passes VO from formBean to BO.
C is not a recommended approach.
D. formBean has DAO helper in base, with an internal collection
(To page) in action you say fB.populate(); (DAO populates)
(From page) in action you say fB.save(); (DAO saves)
baseBeans basicPortal uses this approach
(works with JSTL and easy to unit test, little code, little GC)
.V
Ted Husted wrote:
> florian wrote:
>
>> i think this has been discussed before.. but wouldnt it be possible
>> to simply
>> have the actionform methods delegate to the value objects accessors?
>> when the form is populated it looks for getter and setter methods, no?
>
>
> Which means it would be an excellent time for someone to summarize
> this (and similar threads) into a HOWTO for the docs, or even a page
> on the Wiki. =:0)
>
> http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsProjectPages%20
>
> -Ted.
--
Vic Cekvenich,
Struts Instructor,
1-800-917-JAVA
Advanced <a href ="baseBeans.com">Struts Training</a> and project recovery in North East.
Open Source <a href ="baseBeans.com">Content Management</a> basicPortal sofware
Best practice<a href ="baseBeans.com">Struts Support</a> v.1.1 helper ScafflodingXPress
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Populating Value Objects for the Business Tier
Posted by florian <cs...@structbench.com>.
On Samstag, Mai 31, 2003, at 06:09 Uhr, Ted Husted wrote:
> florian wrote:
>> i think this has been discussed before.. but wouldnt it be possible
>> to simply
>> have the actionform methods delegate to the value objects accessors?
>> when the form is populated it looks for getter and setter methods, no?
>
> Which means it would be an excellent time for someone to summarize
> this (and similar threads) into a HOWTO for the docs, or even a page
> on the Wiki. =:0)
excellent idea, ted =)
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Populating Value Objects for the Business Tier
Posted by Ted Husted <hu...@apache.org>.
florian wrote:
> i think this has been discussed before.. but wouldnt it be possible to
> simply
> have the actionform methods delegate to the value objects accessors?
> when the form is populated it looks for getter and setter methods, no?
Which means it would be an excellent time for someone to summarize this
(and similar threads) into a HOWTO for the docs, or even a page on the
Wiki. =:0)
http://nagoya.apache.org/wiki/apachewiki.cgi?StrutsProjectPages%20
-Ted.
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org
Re: Populating Value Objects for the Business Tier
Posted by florian <cs...@structbench.com>.
On Donnerstag, Mai 29, 2003, at 06:28 Uhr, Jordan Reed wrote:
> All,
>
> I'm on a team that's trying to decided on a best practice for passing
> on
> populating our value objects that get passed to our business layer. We
> currently have three techniques we've though up and I'm wonderful if
> anyone
> has a strong opinion on which one may be the "best" and why.
>
> The basic problem is that the user enters information into a form.
> The form
> is a presentation object, and should not be passed to the business
> layer.
> So it's information needs to be in a presentation-agnostic interface
> before
> being passed to the data layer.
>
> 1) Have the action class copy information from the form to a value
> object.
> Have a view helper copy information from the value object into the
> form (for
> pre-population)
>
> 2) Have the form implement a value-object-like interface. The business
> layer accepts objects with these business interfaces. This way it is
> possible to pass the form objects to the business layer without the
> business
> layer knowing that they are presentation objects.
>
> 3) Have the form simply include value objects as properties. Then use
> the
> nested taglibs to populate the value objects. This way the Action can
> just
> pull the value object off directly and pass to the business layer. A
> view
> helper can just set the value object on the form.
i think this has been discussed before.. but wouldnt it be possible to
simply
have the actionform methods delegate to the value objects accessors?
when the form is populated it looks for getter and setter methods, no?
ciao!
florian
---------------------------------------------------------------------
To unsubscribe, e-mail: struts-user-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-user-help@jakarta.apache.org