Hi Phil - I suppose that in all things OO (or programming, or life), an answer would be "it depends on the context."
I don't think that lazy creation is a good idea at all (especially when you're in the context of line items needing to be children of or associated with a parent order --- transactional integrity and all, you know), but when it comes to getting back smaller chunks of a larger object or updating the properties of a container object, I do think there are a number of options: * If the context of lazy loading you're talking about here refers to, say, getting a high-level snapshot of all orders made by a particular client where only the date of order and total cost is relevant, why not simply return a query instead of an array of objects which may be significant in size and costly to parse through? Yes, a query isn¹t a well-encapsulated business object, but in terms of simplicity and performance, that may be the way to do for simple snapshots or overviews where getting the complete object isn't necessary. * If the entirety of your object is created, read or updated at one time, you could, possibly, check for the existence of composed objects (like LineItems) and then, if none exist within the given object, don't bother to update them in the database (or whatever persistence mechanism may be used). That is, you could say <cfif ArrayLen(LineItems)> -- Update LineItems in this Order </cfif> And the updating of the composed objects would only happen as needed. You could do something similar for reading, wherein you set a flag that says "only get me the order object but none of its composed lineItems," or, better yet, have a separate DAO.read() function which handles reading only the parent order object but not the composed lineItem objects. If you are concerned that the complexity and number of objects which may be loaded in to memory at any given time will adversely affect application performance, you may have to break apart object instantiation and updating to handle lazy loading/updating. I, personally, would try to keep things together and simplify as much as possible. It's not always easy (some days my brain hurts trying to work out the cleanest ways to compose objects into other objects in CF), but I think it just makes my DAO functions more cohesive. RAM is also really cheap and I'd pay for the extra 2GB of RAM per server to handle memory issues rather than create something that is more complex and difficult to maintain (and understand by developers coming in to an application after me). But that's just me. You've probably already thought about all this, but I thought I'd throw my $.02 in to the ring. brian on 8/31/05 2:05 AM, Phil Cruz at [EMAIL PROTECTED] wrote: > Say you have an object that is composed of other objects, for example say we > have Orders and Orders have LineItems. You may have an OrderDAO that has a > LineItemDAO. I'd like to hear how people approach lazy loading and/or lazy > updates. Meaning that if I'm only reading/updating data on the Order I don't > want to read/update all the LineItems. > > -Phil > ---------------------------------------------------------- > 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] ---------------------------------------------------------- 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]
