Drew Cox wrote:
> Well, thanks everyone for your responses, especially Slava - although I have
> to admit to not quite following the metaphor. I guess supermarkets in
> Australia operate differently?
>
> But, seriously, after digesting the comments of all invovled and also having
> completed some more of the system design, I am leaning back towards separate
> classes for each web action. I have rationlised the number of separate web
> actions required to a more manageable number.
>
> I was however, a little confused by some of the comments against web actions
> mapping to a designated class and method. I was not planning to have
> different parameter lists on these methods, just the normal
> HttpServletRequest and HttpServletResponse, the same as with the command
> pattern action( ) method Craig spoke of. And I was generally not planning
> on storing these beans in the session, but caching them at the application
> scope. So as I see it, the only practical difference is the extra
> complexity of using Reflection techniques to invoke the dynamic method name,
> instead of the well-known method name in the Command interface.
>
Besides complexity, there is also a performance impact to using reflection on
every request. If you declare all your action classes to implement a particular
interface (I use "Action", for obvious reasons :-), then the only cost of calling
the method is a Java cast to make sure the class you just loaded actually
implements Action. Using relfection means you need to set up the arguments to
your call in separate objects, and then call a method (inside the reflection API)
that goes and finds which actual code to execute.
On one of my projects, we evaluated an approach to load balancing that implemented
forwarding of requests to other servers, and the actual resolution of what code to
call was done with reflection. Benchmarks showed a performance impact of 5-10% on
every call (versus direct method invocations), which is worth it in some
environments, but probably not inside a servlet based web application.
If you're not going to vary the argument sequences, separate classes per action
(all implementing a common interface) is definitely the way to go from the
performance perspective.
>
> However, I believe there is something to be said for avoiding complexity if
> you don't need it. And as I am leaving this employer shortly, implementing
> a commonly used design pattern that is more likely to be understood by
> future developers is also desirable.
>
Thanks Drew, you just restored my faith in humanity :-). Most developers I know
would be tempted to obfuscate the code because they know they won't have to
maintain it.
>
> Regards
>
> Drew
>
Craig
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
FAQs on JSP can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
