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 > > > --------------------------------------------------------------------- > 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] > __________________________________ Do you Yahoo!? Yahoo! Calendar - Free online calendar with sync to Outlook(TM). http://calendar.yahoo.com --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
