Given the comments from Craig on not using Value Objects as form beans our project is taking the following approach.
We are creating a "helper" class to transform our ValueObject (Data Transfer Object as we call it) into a form bean (Strings, Boolean, and boolean types only) and the reverse. I started this effort by looking at the code within the beanutil package that is part of commons. Unfortunately, object composition is not supported (User object contains an Address object) within the commons code base. So, I've taken to writing our own transformation helper and take advantage reflection and the convertion utilities provided in the commons package. Granted this is not an approach that a small project should take, but ours is a fairly large project and we wanted to create a "Helper class" to assist in transforming the data between tiers. The idea is that each interface (Struts being the HTTP interface) will have it's own helper class to assist in this. I will reduce a little coding, but provide easy tranformation of the data between tiers. Currently, the transformation helper class is dependent on our own package structure. :-( I'm hoping to be able to refactor this so that it's configurable like the ConvertUtils does and I'll offer it up if people are interested. Also, since we are only prototyping right now, I don't provide support for Collections, but I do provide support for Object Array types (e.g. User[] user). The intent is to provide Collection support in the future, but I must utilize a "type safe" collection that is initalized with "type" or it's class that will be stored at initialization in the target object so the transformation utility knows what class to create when transforming an object from one collection to the other. We are using the same names for our attributes and classes, it's just different data types. The DTO (VO) contains mixed type, java.sql.Date, java.lang.Float, etc. The FormBean currently only has String, Boolean and boolean types. Hope this helps give an idea on another approach. Steve >From: Ted Husted <[EMAIL PROTECTED]> >Reply-To: [EMAIL PROTECTED] >To: Struts Users Mailing List <[EMAIL PROTECTED]> >Subject: Re: Value object doubt !!! >Date: Fri, 24 May 2002 08:47:27 -0400 > >The best stategy will depend on what else is going on with your >application. > >The ActionForm is really part of the control layer and so can interact >with objects on both the presentation and business layers. > >A generally useful approach is to put a factory method on the ActionForm >that returns your value object. > >This neatly encapsulates the data transfer. All the Action has to do is >call the method and pass along the result. > >Which I guess is your #2. > >-- Ted Husted, Husted dot Com, Fairport NY US >-- Developing Java Web Applications with Struts >-- Tel: +1 585 737-3463 >-- Web: http://husted.com/about/services > > >Radhika Nadkarni wrote: > > > > hi, > > Im having an action Form. Im using Value object for data conversions. > > Now my problem is i have two scenarios for implementing the same : - > > 1) Value object will be separate > > 2) Value object will be composed within the Form Bean. > > Can anyone tell me which is the best strategy out of the two ? > > > > _________________________________________________________________ > > Get your FREE download of MSN Explorer at >http://explorer.msn.com/intl.asp. > > > > -- > > 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]> > _________________________________________________________________ Chat with friends online, try MSN Messenger: http://messenger.msn.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
