Something like this in Application.cfm (I'm leaving out locking for simplicity):
<cfif NOT structKeyExists(application,"cfc")>
<cfset application.cfc = structNew()>
<cfset application.cfc.someService = createObject("component"....)
<cfset application.cfc.someOtherService = createObject(...).init(application.cfc.someService)>
[etc.]
</cfif>
(using the init method you get "constructors" where you can do things like pass instances of one cfc to an instance of another to preserve encapsulation)
If you want, you can also build a facade that encapsulates the application scope, but in most circumstances you shouldn't need that. This kind of thing does require some extra work "up front" to ensure that all "services" that need to use each other are passed the appropriate references at init time (to be sure you aren't having to make arbitrary assumptions about the existence of the application scope), but that has seemed like a reasonable trade-off in the applications where I've used/seen this approach.
At some level, in a CF app you will have places (page-level code, mostly) that can be aware of the application scope (that is, can be assumed to be executing under the context of the Application.cfm), and those places can then be used to manage any lower-level passing of CFC information where encapsulation prevents direct access to Application scoped component instances.
Matt Liotta wrote:
----------------------------------------------------------i'm sure you've thought of this, but why not use a simple "if NOT isDefined('application.myManager')" statement? I'm just curious why you're not doing the obvious here.
Where do you execute that simple line of code? In every place you ever need to get a reference to the singleton CFC? That code needs to be encapsulated thus suggesting it should be in a CFC that "manages" other CFCs. However, that approach leads to the problems I mentioned in the first email.
-Matt
----------------------------------------------------------
You are subscribed to cfcdev. To unsubscribe, send an email
to [EMAIL PROTECTED] with the words 'unsubscribe cfcdev' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
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' in the message of the email.
CFCDev is run by CFCZone (www.cfczone.org) and supported by Mindtool, Corporation (www.mindtool.com).
An archive of the CFCDev list is available at www.mail-archive.com/[EMAIL PROTECTED]
