"Shun, Vadim" wrote:

> [snip]

> Another approach is to leave business logic in Command/Action class and let
> the bean be just a placeholder for information (text, numerical, date) to
> pass to JSP and back. An advantage of this approach is that apparently that
> passing "lean" bean deprived of any functionality except for mutators and
> accessors most likely should be faster.

I've used both the design patterns you describe depending on the specifics of the
app involved (but have tended towards business logic in the beans, which maps
nicely to EJB session beans for more complex applications).  However, I don't
understand how lean beans would be "faster":

* The thing that is passed (in the request or session attributes) is a
  reference to a Java object, which is independent of the size of that
  object.

* Speed of access from a JSP bean to the attribute is going to be
  dependent on how many beans there are, not the size of the beans.
  (Most servlet containers use a Hashtable or something like that to
  store request and session attributes.)

* The getXxxx methods that the JSP page calls when creating the UI
  are still typically going to be implemented as returning an internal
  instance variable.  Again, this should be independent of the size of
  the bean itself.

Also, note that even if your business logic is embedded in beans, you still need
the action class as a GoF "adapter", transforming the HTTP request properties into
appropriate setXxxx calls.

Craig McClanahan

===========================================================================
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

Reply via email to