On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: [snip] > By combining Actions and ActionForms, you are breaking the separation. > There *IS* clearly benefit to doing so... cutting down class count is > something I'm always in favor of, so long as line count doesn't increase > as a result. But is it worth it?
I think of the state information represented by an ActionForm (in Struts 1.x) or potentially as properties of an "action" class (per the current discussion) to be part of the *view* tier. Further, I see the role of the execute method on an action as being an Adapter Pattern link between the web tier (HTTP-centric) and the model tier (HTTP-agnostic). Therefore, I don't feel any pain at the idea of combining the two together. The primary mistake to avoid is using an ActionForm as a VO passed to your persistence tier. This seems a little less likely when the same object has behavior as well as data, but you still need to watch out for this. > Clearly some now believe it is... as I understand it, that's one of the > important concepts in JSF and ASP.Net, among others. > I wonder, would you think there is benefit to combining the two over a > declarative approach like DynaActionForm? Using them you cut the class > count down similarly, and in fact *REDUCE* overall line count as well, > and you gain a declarative approach to things, which is definitely nice > (I seem to remember that's how JSF approaches things, but it has been a > while since I looked, my memory may be fooling me). That (combined "action form" and "action" concept) is indeed the recommended design pattern when using JSF, as well as with WebWork, which uses the same idea. Although it does reduce the total line count slightly, this is outweighed, IMHO, by other advantages: * The input values are available as instance variables in your "action" class, which makes coding accesses to those values a little simpler (foo instead of formBean.getFoo()). * Because of that, there's a little less per-request object creation going on (although you trade that off for the "action" class being instantiated per request, so it is almost a push). * At least in the JSF case, the component handles conversions for you, so "foo" can be an int if the value is supposed to be an integer. No more BeanUtils.copyProperties() calls. * The code becomes easier to unit test because your test case simply has to instantiate your "action" class, set the appropriate properties, and call the execute() method. Lots less to do setting up mock objects that simulate a servlet container. As I've said publicly on more than one occasion, if I'd thought of this approach (action class with properties for the request variables, instantiated per request) early enough, this is what Struts 1.0 would have done. Alas, by the time the value of this pattern became clear, backwards compatibility was an important issue, and we couldn't change. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
