Craig McClanahan wrote:
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.
It sounds like what your saying is that there really is no need for a control layer, we're coming down to view-adapter-model now. Am I understanding that correctly?
I absolutely agree that the ActionForm, or properties of Action, is indeed part of the view. And, as per your next paragraph, I absolutely agree we shouldn't be passing that state information, in either form, directly to the model.
So, in my mind, if we are talking about a single class that has properties of the view layer, as well as an adapter to the model in execute() (which we may or may not still call the control layer I suppose), that feels like co-mingling two tiers, something we have always convinced ourselves is a bad idea.
Further, what would stop something from stretching a bit further and saying that DTOs from the control to the model should be in the form of maybe an inner class in the Action, further co-mingling in the model tier, arguably?
I'd be very interested to understand why, assuming my interpretation is correct to begin with, we should start to think differently now about the mixing of parts of various layers in a single entity. I don't ask to be confrontational at all by the way, but its an interesting discussion to me.
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.
Agreed, that is indeed the real problem to avoid in the end. How best to accomplish it might be debatable, but I think we all agree this is the gotcha to avoid :)
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()).
That is one benefit I definitely like as well. Although it has never caused me personally any major heartache that you can't do this with Struts, I have seen instances where it would have made life a little simpler.
* 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).
I've always wondered about how big a help it is to not be instantiating Actions per-request (although I suppose I haven't wondered it enough to do any benchmarks myself :) ). It always seemed perfectly reasonable that it was a benefit, I've never doubted it was, but I've always wondered if it was truly worth the trade-offs.
* 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.
Indeed, that is a nice benefit.
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.
Eh, live and learn. No one gets it right every time out :) And it isn't like you got anything *wrong* per se anyway, you figured out something better later on. The developer that has never had a revelation after the fact is a better developer than any of us for sure!
Frank --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
