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".
begin:vcard n:Wilson;Chip tel;work:214-642-4559 x-mozilla-html:TRUE org:Axys Solutions adr:;;14001 North Dallas Pkwy;Dallas;TX;75240; version:2.1 email;internet:[EMAIL PROTECTED] title:Director, Enterprise Java Practice note:Sun Certified Java Architect, J2EE Platform fn:Chip Wilson end:vcard
