Re: Populating Value Objects for the Business Tier

[florian]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Populating Value Objects for the Business Tier

[Ted Husted]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Populating Value Objects for the Business Tier

[Ted Husted]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



--
Ted Husted,
Struts in Action 


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Populating Value Objects for the Business Tier

[florian]

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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

RE: Populating Value Objects for the Business Tier

[Steve Raeburn]

ActionForms should carry a Strings only health advisory ;-)

Steve

> -Original Message-
> From: Jordan Reed [mailto:[EMAIL PROTECTED]
> 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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> > 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: [EMAIL PROTECTED]
> For additional commands, e-mail: [EMAIL PROTECTED]
>
>


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Populating Value Objects for the Business Tier

[p]

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" <[EMAIL PROTECTED]> 
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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]



-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Populating Value Objects for the Business Tier

[Jordan Reed]

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" <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> 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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Populating Value Objects for the Business Tier

[Vic Cekvenich]

+ 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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
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 interf

RE: Populating Value Objects for the Business Tier

[Mike Duffy]

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 <[EMAIL PROTECTED]> 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:[EMAIL PROTECTED]
> 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
> 
> 
>
---

RE: Populating Value Objects for the Business Tier

[Andrew Hill]

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:[EMAIL PROTECTED]
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]


-
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]

Re: Populating Value Objects for the Business Tier

[guo yingshou]

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 <[EMAIL PROTECTED]> 的正文：>
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:
> [EMAIL PROTECTED]
> For additional commands, e-mail:
> [EMAIL PROTECTED]
>  

_
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: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]