First, I just want to make it clear that I'm not necessarily disagreeing with your position. I'm just trying to better understand the reasons behind it. I have seen a lot of variations in the way Struts applications are coded and each approach has its pros and cons. I'm just trying to sort out which approaches tend to cause more pain and sorrow than others and why.
JM: While this is a style thing to be sure, the basic answer I would give is "that's not what they're for". I believe in strict separation of responsibilities. According to the Struts user guide:
An ActionForm represents an HTML form that the user interacts with over one or more pages.
But isn't that just half of its responsibility? To review, an ActionForm exists for the following reasons:
1. To serve as an abstraction for the request parameters. Struts automatically matches request parameters and ActionForm properties. Struts also performs type conversion from
String to the property's actual type whenever necessary.
2. Provide front-line validation of property values via the validate() method. There is often confusion as to what kind of validation should be performed in this method. To add to this confusion, an alternative method of validation is available in the validation framework.
3. To make the values obtained from the client request available to other tier(s) (control?, business?, persistence?).
JM: To my mind, not only do DTO transfer methods (one method for each direction of transfer) not fit in with an ActionForm's role and responsibilities, they couple the class unnecessarily to the DTOs. OK, let's examine the kind of coupling that results with this approach. Obviously, we do not want to totally eliminate coupling since these objects need to work with each other. What we really want to do is manage the dependencies such that code changes have minimal collateral impact.
If you think about it, the ActionForm is already dependent on the underlying Model object at the attribute level because it represents some or all of the Model attributes. If you add an attribute to the model, the ActionForm is likely to require a change as well.
The Action is also dependent on the Model but at a higher level than the ActionForm. A change to the Model will not necessarily require a corresponding change in the Action.
Since the ActionForm is already coupled to the Model at the attribute level, would it be better to make the ActionForm responsible for stuffing the DTO that will be passed on to the Model? Doing so would concentrate the code that gets affected by changes to the Model in just one class: the ActionForm. Wouldn't this be a good thing?
If instead, we make a helper object responsible for extracting values from the ActionForm and stuffing a DTO, then won't we increase the number of dependencies within the application? That is, the helper class is now dependent on the ActionForm and the DTO and the ActionForm is now dependent on the ActionForm, the business object, and the helper.
[ June 10, 2004: Message edited by: Junilu Lacar ]