On 7/11/05, Craig McClanahan <[EMAIL PROTECTED]> 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. > > 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.
Very few had the idea of passing ActionForm as VO to persistence layer. This is some kind of backwards MVC. Contrary, the idea was to use BOs in ActionForm with session scope, thus making it a stateful interactive business object. I am not sold on the idea that presentation should have state. Why? Presentation presents. Business objects have data and state. If I aggregate BO into view, I do not break classic MVC design. Instead, I gain in terms that I have my data in one place instead of two places. This is classic database rule: if you can have data in one place, have it there. This saves from discrepancies and is easier to maintain, to understand and to follow the relationships. Treeviews may contain business data, or may not, so I see value of having things like treeviews in view layer. Comboboxes are usually not a business data, busines data is only one value from this combobox. Regular data that comes from database and edited by user, is busines data, and it is much easier to pull it from a real BO and to display it. > The JSF recommended pattern actually lets you do "dispatch action" > sorts of things, but a bit more easily :-). JSF isolates business data from widgetse even further. Also, JSF is not advertised as framework where a resource returns different views. Instead, it is advertised as Page Controller, which works well for former desktop programmers, but does not fit HTTP ideology. Not that it is not possible to emulate Front Controller in JSF, but it takes some tricks for that. Same goes for ASP.NET - easy to develop, clumsy to use. Of course, Microsoft provided option to not use _viewstate, but everybody uses it, because it is used in sample code and is considered standard. I am glad that JSF stores viewstate on server by default, this is much better. Michael. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
