On 7/11/05, Frank W. Zammetti <[EMAIL PROTECTED]> wrote: > 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? >
Not completely, but amost. There are reasons to have an "application scoped" front controller. There are reasons to have a "view-scoped" front controller. There is *no* reason I am aware of that requires these controllers to be the same :-). In Shale, the application-scoped functions are performed by a Commons Chain pipeline that is configured and processed by Shale's filter. This is the right place to put things like "if the user isn't logged on, redirect to the login page" and "log every request" type functions. But it is not the right place for "execute this expensive SQL query, but *only* if I am the view that needs it.". In Struts 1.x, you get around the latter case, typically, by having a setup action before the view, and a process action after the view. Shale simply combines those two bits of code into a single class (and, along the way, combining the form bean too), resulting in a little less code, but a lot fewer classes. > 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. > See above. > 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? > People do that with form beans already, so we clearly haven't succeeded in communicating the correct pattern :-). But, if you do the right thing in Struts 1.x, you already have zero model tier code, or business logic, in your actions -- they are already performing the adapter role. > 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. > It's not about mixing layers. It is about mixing all the parts of the *same* tier (view) related to a particular page into a single class, instead of three classes (setup action, form bean, and process action). The adapter has to be somewhere no matter what; co-hosting it in a single class turns out to have benefits in terms of simplicity and unit testability. WebWork and JSF got this one right. > > 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. > In 1.1 and 1.2 JDKs (i.e. when Struts was invented), this mattered a *lot*. In 1.4 JDKs, it basically doesn't matter unless you have *huge* request volumes. Thus, the reasons for most people to not put their adapters in request scope is basically gone. > > * 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! > Just remember ... the lifetime of Struts 1.x (five years since initial conception, four years since 1.0) is basically a geologic era in terms of Internet time :-). > Frank > Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
