I think this also relies on context as well - I mean, if you KNOW you have to have the roles straight away, there seems little point in loading them later.
Or if you know that you already have the roles in some sort of persistance manager, it may well just be very easy to pull them out of there (no db hit) when you create your person. Also dependent on how you structure your SQL as well - if you have a seperate SELECT statement for each of the objects, you are looking at a fair bit of overhead, but if you can cut it down to one SELECT statement for all the objects, maybe it's not entirely unreasonable to build one big composite object. Lots of different ways to skin a cat, yet again :o) Mark On 8/23/05, John Farrar <[EMAIL PROTECTED]> wrote: > > I would also think you could check to see how many objects are in the role. > If there are no objects... instantiate, else use existing object. Interested > to hear what the popular pattern methods are on something like this... but > it seems that unless it's an always called has object, then this would be > the better design. > > John > -- E: [EMAIL PROTECTED] W: www.compoundtheory.com ICQ: 3094740 ---------------------------------------------------------- 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). CFCDev is supported by New Atlanta, makers of BlueDragon http://www.newatlanta.com/products/bluedragon/index.cfm An archive of the CFCDev list is available at www.mail-archive.com/[email protected]
