On Thu, 17 Jul 2003, Mike Jasnowski wrote:
> Date: Thu, 17 Jul 2003 12:37:39 -0400 > From: Mike Jasnowski <[EMAIL PROTECTED]> > Reply-To: Struts Users Mailing List <[EMAIL PROTECTED]> > To: Struts Users Mailing List <[EMAIL PROTECTED]> > Subject: RE: Question on making Action classes thread-safe > > Do you think though that this would be a nice convenience or would just > encourage bad > practices too much to be worth it? Also assuming that the overhead was > acceptable (define acceptable) If we were going to do that, I think it would be better to combine an ActionForm and an Action into a single concept, so that the Action would have direct access to the form values as instance variables. In essence, this is how WebWorks does it on this particular issue, and it's a pretty elegant design. (It's also a pattern I expect to see in a lot of JavaServer Faces based code -- it's really easy to set the valueRefs for your form fields and the actionRefs for your actions to point into the same back-end bean, so that the action methods can access the form field data directly.) The risk, of course, is that developers will become tempted to intertwine business and presentation logic to the detriment of long term maintainability ... but I think good design patterns can continue to illustrate the right way to do this (you'd still delegate to separate classes for the real business logic, for example, just like you should do from your Action classes today). When Struts was designed, the overhead of instantiating objects and the subsequent GC was a much more important issue. I suspect that it's not a big deal on modern JVMs -- and we're already paying the per-request object create overhead for form beans (if you use request scope), which doesn't seem to be fatally flawed from a performance perspective. The challenge for Struts, of course, is how to do things like this and maintain backwards compatibility so that existing apps do not need to be rewritten the next time the user switches revs. Craig --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
