If the latter, the server scope would seem to make a lot of sense, given that it's the least dependent on the environment in CF (though, if the app needs to run on a shared server it obviously has other issues). If the components that need access to whatever the "manager" is going to do, presumably they can assume they are running inside the context of the application in which the manager lives -- so, although it's not perfect, breaking encapsulation that small amount would probably be acceptable to gain the performance benefits of your single-point of entry (allowing you to build in a caching mechanism for your component instances), and the manager, as others suggested, would make it so that your breaking of encapsulation is, well, encapsulated.
If the former, perhaps you can refactor such that you don't need lots of instances for a given request and can instead use a more central, single CFC (that can be cached in a shared memory scope you don't mind passing around too much). In one application I've worked on this ended up being accomplished most cleanly by having a single "globalVarsService" component cached in the Application scope -- it acted as a facade for the rest of the Application scope, and it had methods that acted like a factory to get other "services" the application used (each of which was itself a CFC instance that the globalVarsService returned references to).
Matt Liotta wrote:
----------------------------------------------------------The Managers component would only be responsible for managing managers, not singletons themselves.
It is the same problem... I have a random CFC that wants a reference to a singleton, so I need to ask a manager for it. Where do I get the reference for a manager? You are suggesting I can get the reference from a manager manager, but where do I get a reference for a manager manager?
You can add any number of levels of abstraction CFCs and the problem is still the same.
-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]
