There are some other reasons, besides the ones you mentiojed (see also Roles in Command pattern in GoF book, I believe Craig approach closely follows this one with its class hierarchy and dependencies). What if your Perform or Execute method to is to return back to JSP a collection of beans. You can accomplish that by a bean creating in a special method a collection of themselves, but this approach tends to be not as clean as having some factory do the job (your Action/Command class can play a role of Factory as well with some success). Vadim Shun NEW Corp Dulles, VA -----Original Message----- From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]] Sent: Monday, April 03, 2000 5:09 PM Subject: Re: More on Model 2 discussion - Interesting option to Action Class approach. 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
