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]
