OO is not alwasy the best way; and there are trade offs for every implementation.
As Jacob mentioned... "It's always on a case by case basis." robert > -----Original Message----- > From: Avinash Gangadharan [mailto:[EMAIL PROTECTED] > Sent: Friday, March 12, 2004 4:46 PM > To: 'Struts Users Mailing List' > Subject: RE: [OT] Object Design Question > > > That's the way I have it now, a view object querying the datastore and > forming the business objects. The view issues a query for the parent and > then calls the views of the children to give their list of objects for that > parent and then constituting the parent completely. I agree getting them > back together and then parsing them out would be better but sure not a clean > OO way of getting data. > > -----Original Message----- > From: Robert Taylor [mailto:[EMAIL PROTECTED] > Sent: Friday, March 12, 2004 1:01 PM > To: Struts Users Mailing List > Subject: RE: [OT] Object Design Question > > > +1. Join the tables in a query and write an algorithm to parse the > +results into > the view you need. One connection, one query, let the database do the work. > Not very OO, but very efficient. > > > robert > > > -----Original Message----- > > From: Hookom, Jacob [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 12, 2004 3:37 PM > > To: Struts Users Mailing List > > Subject: RE: [OT] Object Design Question > > > > > > It's always on a case by case basis. When and how much do you need at > > a given time? Hibernate/JDO/OJB/etc can handle these things for you > > via a config to specify lazy relationships. > > > > When you are talking about web application with read data (data purely > > pushed to the view like a list of persons with addresses), then the > > best way IMHO is to write a special view object and query for this > > case. > > > > List View Objects > > Select By Id > > Grab Business Object By Id > > > > > > > > -----Original Message----- > > From: Avinash Gangadharan [mailto:[EMAIL PROTECTED] > > Sent: Friday, March 12, 2004 2:26 PM > > To: '[EMAIL PROTECTED]' > > Subject: [OT] Object Design Question > > > > People, > > I have a design question. It is regarding the retrieval of parent > > and child objects in the best possible manner. For eg. Let's say there > > is a Person object with properties such as ssn, lastName and > > firstname. It also has a list child objects ( "Address" ) of addresses > > and a list of previous employees ( "Employee" ). The Person, Address > > and Employee objects are separate tables in the DB linked thru ssn. > > > > Now what do you guys think is the most efficient way of retrieving a > > complete Person. > > > > The simplest way is ofcourse issue 3 queries one for person, other for > > the list of address and the third for previous employees. But this > > does not scale well with increasing size of the table data. For 100 > > rows of Person 201 queries are issued. 1 which gets 100 persons, 100 > > each for there subequent address and previous employees. Similarly for > > a 1000, 2001 queries. > > > > Complex queries may be a solution which relies on filtering the > > resultset but is there a more simple and intelligent approach. > > > > Is there a problem with the inherent design itself or is this a common > > problem. > > > > Thanks and Regards > > Avinash > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > > To unsubscribe, e-mail: [EMAIL PROTECTED] > > For additional commands, e-mail: [EMAIL PROTECTED] > > > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > > --------------------------------------------------------------------- > To unsubscribe, e-mail: [EMAIL PROTECTED] > For additional commands, e-mail: [EMAIL PROTECTED] > --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
