I recently dealt with lazy loading dealing with a studentEnrollment object and that student's achievements.
I didn't need their achievements most of the time; but on one screen I needed to show them along with any accompanying comments. Since I show studentEnrollment information in a lot of places, but the achievement subset of info in only one I decided to use lazy loading on it. My studentEnrollment object ended up with a new property - achievementsLoaded and a new pair of private methods isAchievementsLoaded and setAchievementsLoaded. Then when I called getAchievements, it would check isAchievementsLoaded if not would follow the appropriate steps to load and set the achievements, including call setAchievementsLoaded method, and then finally return the achievements. If isAchievementsLoaded returned true then studentEnrollment would just return the variables.instance.achievements array (a collection of achievements). Bill On 8/31/05, Brian Klaas <[EMAIL PROTECTED]> wrote: > 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] > > > -- [EMAIL PROTECTED] http://blog.rawlinson.us If you want Gmail - just ask. ---------------------------------------------------------- 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]
