I've used this idea, but extended it a bit. I usually have three beans
associated with a domain object. One is a 'brief' bean that contains the
properties of the object that a user would typically want to see as a result
of a search. One is the complete domain object (that extends the brief
object) and one is a 'resultset' bean that has a Vector of briefs along with
some other navigational data. The 'complete' bean has a retrieve method to
get one record out of the underlying database and the resultset bean has a
search method for retrieving multiple records from the database.
Donald
>
>
> comments below.
>
> > -----Original Message-----
> > From: Craig R. McClanahan [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, June 22, 2000 6:44 PM
> > To: [EMAIL PROTECTED]
> > Subject: Re: A design question
> >
> >
> > Louis wrote:
> >
> > > Hi,
> > > I use model 2 in my web application. I have a question
> > > about design a bean.
> > > I'm not sure whether I want to create a big bean or many
> > > small bean. For example, I can create a bean that contain
> > > employee personal info, and another bean that contain
> > > employee payments, etc. Or, create only one bean that
> > > contain all the info.
> > > Is there any different btw this? Can anyone tell me
> > > which method is good? Passing the big bean, will it be slow
> > > down the performance? or use more memory?
> > >
> >
> > Since the beans all stay in the server's memory, there isn't
> > really much performance difference between one big bean and two small
> > ones. You should design your beans based on object oriented design
> > principles, rather than worrying about performance.
> >
> > The "rule of thumb" that I use is if all the information is
> > about one thing (like an employee in your case), *and* there is only
> > one copy of all the fields, I make it all one bean. 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.
>
> we've wrestled with the same issues on our project. our approach has
> been to wrap in a "results bean" whatever domain objects or data from them
> need to be exposed to the JSP which might need them for display. the
> interfaces to these results beans are fat--like a big facade to the
> results--
> but this seems preferrable to the JSP having to worry about the interfaces
> of possibly many different domain objects. the JSP writer is more or less
> insulated from changes to the API of those domain classes, and can focus
on
> the API of a class representing the results for that JSP to consume.
>
> has anyone else taken this approach? merits? drawbacks?
>
> cheers,
> p
>
> --
> // Paul Holser, Infrastructure Specialist
> // Phone: 972.726.4560/1.800.OBJECT1 x4560
> // E-mail: [EMAIL PROTECTED]
> // ---------------------------------------
> // ObjectSpace, Inc.
> // The Leader in Business-to-Business Solutions
> // http://www.objectspace.com
>
>
===========================================================================
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
