Thanks for all your responses - they've certainly supplied a lot of food for thought.
Chip Wilson wrote:
> There are many discussions of this problem in the archive. I can remember
> discussing this in 4Q98.
>
> I call this the Summary-List-Detail-Dialog pattern of UI design. Usually, the
> actor is searching for something but they don't have enough information to
> identify it exactly. They specify some search criteria and the application
> presents a list of objects that match the criteria, along with enough information
> about each object so that the actor can identify the exact object they are
> looking for. An important aspect of the use case is that the list is read-only
> and the actor will be identifying a single item in the list for update, if they
> update at all.
>
> The best and most elegant way to solve this problem in an EJB architecture is to
> create a summary object that has the information that will be displayed in the
> list plus the primary key of the entity that it represents. This object is part
> of the application model layer, while the entity bean it represents is part of
> the domain layer of the application.
>
> Use a session bean to retrieve all of the data for the search criteria in a
> single query. Map the result set to the summary objects in the session bean.
> Return a serialized vector of summary objects from the session bean to the
> client. The client displays the list and allows the actor to identify the
> summary object which represents the entity s/he is looking for. Once it is
> identified, the actor takes some action (like double-clicking in the list), and
> the primary key from the selected summary object is used to instantiate the
> correct entity bean. I've done it, it works, it's efficient and it's fast.
>
> Tim Fox wrote:
>
> > Umm..
> > It seems you're suggesting doing a table join in code.
> > I've always thought this practice somewhat dangerous - you're essentially
> > competng with programs like Oracle which specialise in doing this.
> > May work for a simple join on two tables, but what about 3 or 4 ?
> >
> > Al Fogleson wrote:
> >
> > > Nothing says that the address has to be an EJB. :)
> > >
> > > You could make the address a class and have it grab all the addresses from
> > > the database, then in the customer bean you can match the address with the
> > > customer using the PK and FK relationship. if you further implement the
> > > address class as a singleton it can retain the result set over multiple
> > > instances of the Entity bean. In your case I would likely use a
> > > findAllCustomers, and spit that back to the rendering engine to put on the
> > > web page. makes for 2 database calls, one to get all the customers, and one
> > > to fill the address class.
> > >
> > > Al
> > >
> > > ----- Original Message -----
> > > From: Tim Fox <[EMAIL PROTECTED]>
> > > To: <[EMAIL PROTECTED]>
> > > Sent: Thursday, May 18, 2000 11:17 AM
> > > Subject: Object-relational problem
> > >
> > > Here's a problem I've been chewing over for a while now and haven't come
> > > up with a satisfactory solution.
> > > It's one of the classic object-relational problems.
> > >
> > > Here's a simplified description (please note that this is a fictitious
> > > example - I've simplified it for clarity)
> > >
> > > I have 2 ejbs: a Customer and an Address.
> > > The customer has a home address.
> > >
> > > I'm displaying a list of all customers satisfying certain criteria along
> > > with their home address on a web-page.
> > >
> > > There would be one customer & address per line.
> > >
> > > This would look something like:
> > >
> > > Customer Name Customer Address
> > > =========== =============
> > > Joe Bloggs 1 High Street, Newtown
> > > John Doe 23 Synchronicity drive, London
> > > Jane Doe 2 Big Street, Badville
> > >
> > > Now the page is hit a lot so I want to get the entire list using one
> > > query - this is pretty easy in SQL - a simple join across the customer
> > > and address tables.
> > >
> > > The last thing I want to do is query for all the customers, then, for
> > > each customer query for the address - this would cripple the system
> > > since I'd have a new query for each row of the page.
> > >
> > > However, if I'm using ejb then it seems I could either:
> > > 1.
> > > Use a finder method to get the list of customers given the criteria,
> > > then...
> > > For each customer in the list, use the findByPrimaryKey() (or whatever)
> > > method to find the address.
> > > This is probably the worst solution since it would probably involve a db
> > > query for each customer address.
> > >
> > > 2.
> > > Use a finder method to get the list of customers given the criteria,
> > > then...
> > > Use a finder method to get the list of addresses given the criteria.
> > > This basically involves running the same (or very similar) query twice -
> > > once in the Customer finder method, and once in the Address finder
> > > method.
> > > This, although better than 1) seems very wasteful
> > >
> > > 3.
> > > Do the query once, and pass the resultset into the finder methods of the
> > > customer and address objects - don't know if this is possible though due
> > > to remote calls and marshalling of the resultset
> > >
> > > 4. Create a denormalised ejb called AddressCustomer which is an
> > > amalgamation of the Address and Customer objects. Yuck!!!
> > > Then I also end up with an AccountCustomer, AccountCustomerStatement,
> > > ProductManufacturerSupplier etc. ad infinitum objects.
> > > Basically the nice OO model gets shot to f*** !!
> > >
> > > I'd been interested in any comments/solutions people have implemented,
> > > as this is really bugging me
> > >
> > > (BTW if I wasn't using ejb I'd use 3) since I wouldn't have any remote
> > > calls problems).
> > >
> > > Cheers
> > >
> > > --
> > > Tim Fox (��o)
> > >
> > > Senior developer
> > > Hyperlink plc
> > > http://hyperlink.com
> > >
> > > email: [EMAIL PROTECTED]
> > > phone: +44 (0) 207 240 8121
> > >
> > > ===========================================================================
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> > > of the message "signoff EJB-INTEREST". For general help, send email to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
> > >
> > > ===========================================================================
> > > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> > > of the message "signoff EJB-INTEREST". For general help, send email to
> > > [EMAIL PROTECTED] and include in the body of the message "help".
> >
> > --
> > Tim Fox (��o)
> >
> > Senior developer
> > Hyperlink plc
> > http://hyperlink.com
> >
> > email: [EMAIL PROTECTED]
> > phone: +44 (0) 207 240 8121
> >
> > ===========================================================================
> > To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
> > of the message "signoff EJB-INTEREST". For general help, send email to
> > [EMAIL PROTECTED] and include in the body of the message "help".
--
Tim Fox (��o)
Senior developer
Hyperlink plc
http://hyperlink.com
email: [EMAIL PROTECTED]
phone: +44 (0) 207 240 8121
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
