On Fri, 11 Oct 2002, Rohra, Prakash N. ,,DMDC/BEAU wrote:
> Date: Fri, 11 Oct 2002 15:59:20 -0400
> From: "Rohra, Prakash N. ,,DMDC/BEAU" <[EMAIL PROTECTED]>
> Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> To: 'Struts Users Mailing List' <[EMAIL PROTECTED]>
> Subject: RE: Struts forms best practice
>
> Craig and other gurus,
>
> Any thoughts on how to re-use the ValueObjects across web/app tiers.
>
> Most of the time people end up defining the "data attributes" in actual
> business objects (where the business logic resides) and also deplicating the
> same 'data attributes' in Value objects. The value objects are then passed
> back and forth between web and app tier. (And then, there are "Form beans"
> also which need the same data members.)
>
> Would it make sense to have "data attributes" defined only in Value Onjects
> and let the actual BusinessObjects (containing the business logic) and Form
> Beans have reference to these Value objects.
>
> So for e.g. a "Person" business object points to PersonVO
> and "PesonForm" points to PersonVO.
>
> Any thoughts??
>
Person->PersonVO is probably ok, although I often see designs where there
are more than one VO per business object (passing through different
subsets of the total number of attribuets), and other designs where a VO
collects data from multiple business objects (or a multi-table select if
you're doing direct database access).
PersonForm->PersonVO seems more problematic though:
* There isn't always a 1:1 relationship between them
* The form bean should still use Strings (rather than native datatypes)
for things like dates and numbers.
> thanks
>
Craig
>
> -----Original Message-----
> From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> Sent: Friday, October 11, 2002 2:27 PM
> To: Struts Users Mailing List
> Subject: RE: Struts forms best practice
>
>
>
>
> On Fri, 11 Oct 2002, Andy Kriger wrote:
>
> > Date: Fri, 11 Oct 2002 13:06:30 -0400
> > From: Andy Kriger <[EMAIL PROTECTED]>
> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > To: Struts Users Mailing List <[EMAIL PROTECTED]>
> > Subject: RE: Struts forms best practice
> >
> > Does this mean that you will have an ActionForm with String fields and a
> > ModelBean that basically has all the same fields but with the correct
> types?
> > And that ModelBean is passed around the struts framework?
> >
>
> The model beans are passed around the back end, and sometimes exposed as
> request attributes for read-only access from the presentation layer.
>
> > If so, how do folks reduce code duplication between the utility ActionForm
> > and the data modelling ModelBean?
>
> Use DynaActionForm or DynaValidatorForm form beans so you don't actually
> have to write form bean classes (except perhaps for custom reset() and/or
> validate() methods). [Requires 1.1]
>
> Make the developers providing your persistence tier logic provide you the
> value objects (after all, they should be reusable in non-web-based apps as
> well) so that you don't have to do all the work :-).
>
> Use tools to generate form bean and/or value object classes from some
> common description of the properties. I understand XDoclet can be used
> for things like this; I'm sure there are others as well. If you adopt a
> strategy of maintaining the data definitions and always generating the
> classes you need, code "duplication" is a non-issue.
>
> >
> > -a
>
> Craig
>
>
> --
> To unsubscribe, e-mail:
> <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail:
> <mailto:[EMAIL PROTECTED]>
>
> --
> To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
>
>
--
To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]>
For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
