Kevin Duffey wrote:
> [snip]
> He made in interesting point. If the action class only implements this
> Action interface, thus the perform() method, (note..this is in my current
> implementation of it, not the more advanced ones Daniel and Craig are
> using), why not eliminate the action class, and put the perform method into
> the JavaBean itself? In this way, since its only one method (in my case so
> far), there are not two classes being used, but one instead. The JavaBean is
> THE action class, so when the perform method is called on the .newInstance()
> of itself, it can use "this.xxx" to store its results in.
>
Interestingly, a very similar approach was supported in JSP 0.92 -- if the bean
you referenced in <jsp:useBean> had a processRequest method that took
HttpServletRequest as an argument, that method would be called when the page was
processed. This was important in the Model 1 application design approach where
you submitted back to the JSP page that created your form. This functionality
was dropped when JSP moved on to version 1.0 of the specification.
One consequence of the proposed approach is that the "action bean" (to
distinguish it from the action class approach we've been discussing) must be
aware that it is operating in a web environment, because you're going to be
passing it an HttpServletRequest (and perhaps a response as well if you use my
approach). This violates a "separation of roles" rule that I apply to my own
designs -- the JavaBeans that implement my business logic are *not* aware that
they are being used by a servlet/JSP app -- they only offer the normal JavaBeans
APIs, so they can be reused in other application environments as well.
A second issue is a little more subtle: how do you *know* that you only want to
talk to one business logic bean? An action class can interact with as many
different business logic beans as it needs to (that's what the "controller" role
in MVC is about), but an action bean is the one and only thing being called to
handle the request, so IMHO you're going to be tempted to combine lots of
business logic that should really be separated, just because you did this
combination.
Again IMHO, more classes isn't necessarily "bad" (nor is it necessarily "good";
the number of classes should be a consequence of design decisions made for other
reasons, not a goal in and of itself) -- what's "bad" in my book is classes that
play more than one role, and are thus harder to maintain and enhance in the long
run. You'll be spending ***lots*** more programming hours over the life of your
app on maintenance than you will on application creation, so ease of
maintenance/enhancement should be an important goal in your original design.
Craig
===========================================================================
To unsubscribe: mailto [EMAIL PROTECTED] with body: "signoff JSP-INTEREST".
Some relevant FAQs on JSP/Servlets can be found at:
http://java.sun.com/products/jsp/faq.html
http://www.esperanto.org.nz/jsp/jspfaq.html
http://www.jguru.com/jguru/faq/faqpage.jsp?name=JSP
http://www.jguru.com/jguru/faq/faqpage.jsp?name=Servlets
