"Shun, Vadim" wrote:
> -----Original Message-----
> Craig,
>
> <Craig>
> 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.
> </Craig>
> Probably I made this statement due to my ignorance.
> When thinking of a whole process, I was imagining that the whole bean with
> its body is serialized and passed, not the handle. Something along the
> lines:
> - JSP is compiled to a JSPservlet
> - ActionServlet to JSPO servlet communication goes most likely through
> servlet chaining.
> - Most likely bean is serialized internally using stream.writeObject on
> ActionServlet end and deserialized in JSPServlet.
> If only bean handle is passed then I was definitely wrong - it is not
> slower.
>
Think of a session as a glorified Hashtable in which your user attributes are
stored. In fact, that is the way many servlet containers actually implement the
attribute get/set stuff. No serialization would ever be needed unless you are in a
distributed server environment, which has a very different set of design issues to
deal with.
>
> <Craig>
> 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>
> Agreed, however remembering recent discussion on it on using reflection to
> achieve this goal (and some even posting a working code here, class named
> FormReader ), your implementing class functionality is rather small, if it
> implements (or aggregates and delegates) to a basic class responsible for
> transferring data from a form to bean class with the same property names.
> Using this approach and delegating business logic to a bean makes
> Action/Command implementing classes rather small -
> 1. call base class FormReader function to set bean properties.
> 2. Call bean method.
> 3. Set bean response in request or session or whatever and forward it to
> JSP.
>
> Using this approach, to avoid bloating bean code we would probably need to
> make bean to be a wrapper for other classes doing the job, since potentially
> a lot of operations can be involved on submitting a form. In addition a bean
> is also a container for properties that forwarded JSP is supposed to read.
>
> I definitely can be wrong here but I think that such an architecture might
> be more difficult to maintain than keeping bean simple, thus closely
> resembling EJB structure:
> Action/Command implementors would correspond to session beans. i.e.
> responsible for logic.
> JavaBean would closely correspond to entity beans, i.e. be a domain.
>
I'm fine with your reasoning about ease of maintenance and decoupling. There have
been design cases that have led me that way, and some where the beans are somewhat
fatter (particularly when I was not using EJBs behind the scenes).
>
> Regards,
>
> Vadim Shun
> NEW Corp
> Dulles, VA
>
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
