is there anything wrong with returning a "collection object" to represent the many "rows" of child data? and that's one of the members of the object?
What is your preferred way of handling this? An Array of objects of the many? A query of the table with the many? A structure...? Other?
something simple: an array of structs, not full blown objects. eg: student ValueObject ========== name: string dob: date timetable: array'o'structs. is there anything wrong with this? my thinking is that it's just data after all and should be handled by the bean as easily as dealing with simple values for the keys. On 5/31/06, Peter Bell <[EMAIL PROTECTED]> wrote:
On 5/24/06, Matt Williams <[EMAIL PROTECTED]> wrote: > > I have a one to many relationship between two tables, or objects. I assume I should somehow store the many in the bean of the one. > What is your preferred way of handling this? > To me it all depends what you're going to do with the many. In general I return ALL views and lists as recordsets unless there is a compelling reason to instantiate beans (why waste the cycles in instantiating or add the complexity of some kind of object pool - there has to be a compelling benefit). I see no reason to return a bean if you're just going to display the properties on the screen (which is the vast majority of page views for most applications). I understand the concept of getters allowing you to perform calculations (or change calculations) for non persistent properties and for a bunch of other special cases, but I find it more performant for my business layer to extend the recordset with any non-persistent properties so it looks to the rest of my application that I do store (say) Age when I only really store date of birth. I know it is important to abstract the calculation of the properties of an instance so you can change the way the property is calculated in one place and then have that propegate without a bunch of code changes. I know one solution to that is a bean with a getter method allowing you to just change the code within the method to change the property. The approach I usually take is to run any such transformations as part of creating my recordset which again abstracts any changes to the calculations to a single segment of code. Does anyone have any concrete examples of why that would be a bad approach? I'm still trying to understand the benefits of a number of the specific OO "best practices" out there - especially those that there are still no agreement on such as beans. If you are going to be editing the instance(s), then it becomes a matter of choice as to how you want to handle the object data. Usually an object (or even some kind of active object) is used and a struct of such objects will be used to handle the case when the number of instances > 1. Best Wishes, Peter -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Robert Munn Sent: Tuesday, May 30, 2006 2:36 PM To: [email protected] Subject: Re: [CFCDev] Opinions on One-To-Many representation in OO I have used a struct of bean objects for the many stored in the one, but only where I know that the number of objects in the struct will be limited. For instance, I have a small content system I put together that stores property beans for content objects in a struct in the object bean. While a content object could in theory have an unlimited number of properties, I know in practice that any given content object will only have a handful of properties, so using a struct is ok. On 5/24/06, Matt Williams <[EMAIL PROTECTED]> wrote: > > I have a one to many relationship between two tables, or objects. I assume I should somehow store the many in the bean of the one. > What is your preferred way of handling this? > > An Array of objects of the many? > A query of the table with the many? > A structure...? > Other? -- --------------- Robert Munn www.funkymojo.com ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected] ---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
---------------------------------------------------------- You are subscribed to cfcdev. To unsubscribe, send an email to [email protected] with the words 'unsubscribe cfcdev' as the subject of the email. CFCDev is run by CFCZone (www.cfczone.org) and supported by CFXHosting (www.cfxhosting.com). An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
