Unless your value objects are expressly designed to act as presentation-layer data transfer objects, you are liable to run into problems when you try this in production.

In practice, ActionForms are the missing String buffer for the HTML controls. It's the place where you can tuck the incoming Strings until you have a chance to look at it and decide whether or not to carry it up to the business layer.

If the ActionForm properties look like your value objects, it's because the *HTML forms* look like your value objects. Eventually, one or the others of these will start to change, and then you will be stuck.

In Struts 1.1, the DynaActionForms severely mitigate the issue of maintaining two classes. You only need to maintain a lightweight XML description of the HTML controls, and Struts will make that into a JavaBean for you. Once you have vetted the Strings, you can then use BeanUtil.CopyProperties to transfer and convert the validated input.

Before long, you may also find that you need to transfer the data to more than one value object. In that case, you could add properties to your DynaActionForm and transfer the properties to whatever value objects need to know.

It is possible to use a business class for an ActionForm, if it was designed to be used that way from the beginning. But that really only works if the beans are being used as a data transfer object on its way to a business facade.

If this is how your value objects where designed, then you could implement the interface as an ActionForm, and then pass that to the facade.

But if you already have an implementation of the value objects, you would probably be better off using the DynaActionForm. The next alternative after that is to wrap the value object in an adaptor, but that won't save you any maintenance.

A lot of people do feel that the ActionForm should be an interface. Since more and more new applications are being designed with MVC in mind, this does start to make some sense. But, Craig would veto that as a product change, so using an interface for an input form could only be done using alternative RequestProcessor or something.

-Ted.

Weissman, Alan wrote:
Ok so I'm a little new to Struts but not J2EE and I've been noticing that my
Value Objects that come out of EJB's in my data layer are the exact same
objects as the ActionForms that are used by Struts....and I'm sure I'm not
the first to notice this.

So here's my question: How can I make one class that can serve as both an
ActionForm and a ValueObject?


The problems with solutions that I've brainstormed are this:

1) I can't make my Value Objects extend ActionForm for obvious reasons.
2) I would rather not use an interface to get around this issue because then
I have two classes to maintain again.

Thanks for any advice!

Alan


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




--
Ted Husted,
Struts in Action <http://husted.com/struts/book.html>



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



Reply via email to