Without lazy loading have a pattern pretty similar to Dave's except I always have services talk only to other services. I don't have playerDAO talk to a fantasyTeamService I instead have the playerService talk to the fantasyTeamService.
Anyway I really interested to hear how other have implemented lazy loading. I know that Barney has a good lazy loading strategy he was telling me about at CFUnited. --Kurt On 10/25/05, David Ross <[EMAIL PROTECTED]> wrote: > Well, without lazy loading, this is simple. My DAO's often utilize > services (such as your AddressService) to assist with the construction > of objects. I'm using ColdSpring to inject my AddressService into my > PersonDAO. The PersonDAO's fetch has code like this: > > <cfset person = createObject(...)/> > > <cfquery name="personQuery"> > ... > </cfquery> > > <cfset person.setName(personQuery.name)/> > > <cfset person.setAddress( > > variables.addressService.getAddressByPersonId(personQuery.id) > )/> > > <cfreturn person /> > > I typically ensure that my DAOs only talk through the service APIs, > meaning they aren't allowed to speak directly to other DAOs. I also > typically only let one service talk to a DAO, meaning that you don't let > multiple services talk to the same DAO. In fact, I usually define DAOs > as inner-beans, meaning that they are effectively "private" to the > service: > > <bean id="PersonService" class="..."> > <property name="personDAO"> > <bean id="PersonDAO" class="..."/> > </property> > </bean> > > Anyways, the difficulty of lazy-loading your Person's address is that > now each and every Person instance needs to know how to find and speak > to the AddressService. I don't like the idea of each instance knowing > how to pull the AddressService out of your BeanFactory. I think the best > option is to manually inject the AddressService into each Person during > construction: > > <cfset person = createObject(...)/> > > <cfquery name="personQuery"> > ... > </cfquery> > > <cfset person.setName(personQuery.name)/> > > <cfset person.setAddressService(variables.addressService)/> > > <cfreturn person /> > > However, once <lookup-method/> is implemented in ColdSpring, my feeling > is that there will be a better solution: your DAO will call getPerson() > each time it needs a new person, and ColdSpring will resolve the > Person<->AddressService dependency transparently (and allow you to > handle lazy-loading with AOP rather than inside the Person). > > I don't have any specific code examples because I've really never had > to do lazy-loading. I am interested in hearing what others do to make it > work. > > -Dave > > >>> [EMAIL PROTECTED] 10/24/2005 10:01:11 PM >>> > I thought about about that option too however, I have many places in > my DAO's were, say a Person object gets read from the DB. The Person > object is composed of an Address. The Address instance gets > automatically initialized when the Person object is initialized. I > hadn't figured out a good way of setting that up using some sort of > proxy to ensure that the Address object that gets created as some way > to reference the AddressService with that PersonDAO or Person service > needing to reference the ColdSpring bean factory in the application > scope. > > Dave you have an example of how you have implemented lazy loading? > > --Kurt > > On 10/24/05, David Ross <[EMAIL PROTECTED]> wrote: > > I would say it's definently not "best" practice for your model to > know > > about ColdSpring (or any other framework), or reference a shared > scope > > (like application). > > > > That being said, if your domain model instances *do* need references > to > > other services, you have options. Obviously you could manually > inject > > your FantasyTeamService using setFantasyTeamService() when creating > the > > FantasyTeam instances. Another option is that the code creating your > > instances is "BeanFactoryAware", meaning that it would ask > ColdSpring > > when it needed a FantasyTeam instance. You would then define your > > FantasyTeam <bean/> with singleton="false" (known as a "prototype"). > > > > The last option is "getter-injection", which ColdSpring will > eventually > > support thru the <lookup-method/> tag. This could help in multiple > ways, > > but in my mind you would end up injecting a getFantasyTeam() into > any > > service or controller class that needed to create FantasyTeams (and > > define the FantasyTeam as a "prototype" same as above). > > > > Either way, one advantage to going with "prototype" beans is that > you > > could actually remove your lazy loading logic inside the bean by > using > > AOP. Your aspect would intercept the getPlayers() method and call > the > > service to load in data as necessary. > > > > -Dave > > > > > > >>> [EMAIL PROTECTED] 10/24/05 8:00 PM >>> > > Sean and others, > > > > Do you think it is ok for my FantasyTeam.cfc to reference the > > application scope to grab the fantasyTeamService from the ColdSpring > > container? This dependence makes me a little nervous although I can > > see nothing really wrong with it at the moment. > > > > --Kurt > > > > On 10/23/05, Sean Corfield <[EMAIL PROTECTED]> wrote: > > > On 10/23/05, Kurt Wiersma <[EMAIL PROTECTED]> wrote: > > > > What kind of techniques/patterns are people on this list using > for > > > > implementing lazy loading. Have played around with a couple of > > > > different ways and haven't been real excited about any of them. > The > > > > best one I have found so far involves taking advantage of > ColdSpring > > > > and having my entity CFC grab a references to its service object > > from > > > > the bean factory. > > > > > > Yup, I'm leaning toward ColdSpring to manage all of that these > days > > too... > > > -- > > > Sean A Corfield -- http://corfield.org/ > > > Got frameworks? > > > > > > "If you're not annoying somebody, you're not really alive." > > > -- Margaret Atwood > > > > > > > > > ---------------------------------------------------------- > > > 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] > > > > > > > > > > ----------------------------------------- > > CONFIDENTIALITY NOTICE: This email and any attachments may contain > > confidential information that is protected by law and is for the > sole > > use of the individuals or entities to which it is addressed. If you > are > > not the intended recipient, please notify the sender by replying to > > this email and destroying all copies of the communication and > > attachments. Further use, disclosure, copying, distribution of, or > > reliance upon the contents of this email and attachments is strictly > > prohibited. To contact Albany Medical Center, or for a copy of our > > privacy practices, please visit us on the Internet at www.amc.edu. > > > > > > > > ---------------------------------------------------------- > > 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] > > > > > ---------------------------------------------------------- > 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]
