"Hines, Bill" wrote:
> Craig,
>
> "On the other hand, if there is a "one-to-many" relationship (in your case,
> one employee with multiple payments), I would make two different beans --
> Employee and EmployeePayment -- and then store one employee bean and as many
> payment beans as I needed to."
>
> How about an employee bean that has an empty Vector of payments as an
> attribute. Is there a downside to doing it that way, so that all employee
> info can be encapsulated together and neatly stored or retrieved from the
> session?
>
No, there's no downside -- that makes a lot of sense. You still need two classes
(one for the enclosing Employee, and one for the Payment), and the Vector is used
to represent a relationship between the two kinds of things.
In the Employee bean, you will probably have some sort of call like getPayments()
that returns an enumeration (or array, or collection depending on how you like to
do this) of all the payments associated with that employee.
Inside a servlet container, the HttpSession object typically uses something like a
Hashtable to store the set of session-scope beans for your application, keyed by
the names you assign. There is virtually no difference in memory occupancy or
access times whether the collection of payments for an employee is stored inside
your employee bean, or separately as a separate session attribute. Therefore, you
should strive to code your beans with the focus on simplicity and maintainability,
rather than trying to worry too much about very small performance differences.
My general advice is that, if you want to focus on performance, worry about things
like "do I run the database on the same server or a different one", "how fast is my
network", and "how many connections should I configure in my connection pool".
These kinds of things represent something like 95% of the performance issues for
large scale web applications. After you have tuned these kinds of things, and your
benchmarks prove that access to session objects is the current bottleneck, *then*
start tweaking the internal object organization. Until then, code clarity is more
important.
>
> Bill Hines, Hershey Foods
>
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
