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
Peter
---------------------------------------------------------------Original Message-----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.
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
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]
