Not sure if I'm following correctly, but here's something I've started
doing. It's a derivative of something I saw in Batfink:
This component that gets scoped to the application scope (it's a service
component). It has some constructors, namely other cfc's it uses internally
(common functions, error related functions).
The point revolves around the transferBean object, which is a cfc I use for
moving data between model and presenter components. I instantiate it in the
component instance within the app scope, but then declare it locally again
within the functions as 'transfer'. The transferBean object has methods for
getting and setting values and errors and as I said is used to encapsulate
data from one cfc to the next. Since the transferBean is a constructor
within a single instance of the cfc (in the app scope) and then is rescoped
locally to the methods of the cfc, does this fit within your idea of
singleton? (Also, if anyone sees any issues with this, please say so since
I'm only now starting to use this method)
<cfcomponent>
<!--- include a copy of the common cfc functions here --->
<cfset common = createobject("component","common")>
<cfset error = createobject("component","error")>
<cfset transferBean = createobject("component","transferBean")>
<!--- include copies of the represented components --->
<cfset categorization = createobject("component","categoryPersist")>
<cffunction name="getCategorizationTree" hint="Gets the
entire categorization tree." access="public" returntype="transferBean"
output="no">
<cfargument name="datasource" type="struct"
required="yes"><!--- contains datasource.dsn, datasource.username,
datasource.password --->
<cfargument name="userGroupList" type="string"
required="Yes">
<cfset var transfer = transferBean><!--
create local instance of the transferBean object --->
<cfset var theTree = "">
<cftry>
<cfset theTree =
categorization.categorizationTreeGet(arguments.datasource,arguments.userGrou
pList)><--- call the persist component --->
<cfreturn
transfer.create(theTree)><!--- return the local transferBean instance with
its value declared --->
<cfcatch type="Any">
<cfreturn
transfer.create("",error.createError(cfcatch))><!--- return the local
transferBean with a generated error as its value --->
</cfcatch>
</cftry>
</cffunction>
</cfcomponent>
-Kevin
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf
Of Matt Liotta
Sent: Monday, September 06, 2004 5:09 PM
To: [EMAIL PROTECTED]
Subject: [CFCDev] singleton pattern
I have an application with various "worker" objects that are wasting
resources for no reason. For example, one "worker" object has on average 51
instances for any given page request. I really only need 1 instance of this
"worker" object, but it does have some instance data. The way I would solve
this with Java is to use the singleton pattern where I can ensure the only
one instance is created and manage that instance data when it is first
created.
Implementing the singleton pattern is Java is pretty easy, but requires two
things that CFCs don't have; constructors and static modifiers. Looking into
how to solve this problem with what CFML does provide I came up with the
following solution.
First, I created a "manager" CFC to maintain data in the application scope.
Second, instead of using CreateObject() to instantiate these "worker"
objects, the "manager" CFC is asked for an instance. The "manager" attempts
to find an instance in the application scope. If it finds one it simply
returns it; else it creates an instance and returns that.
The above solve the problem of having more "worker" instances than needed
and makes a huge difference in terms of performance. However, now there are
a ton of "manager" instances, which isn't bad in terms of performance since
they are small and have no instance data. But, I don't need a bunch of
"manager" instances either.
Somewhere, somehow, something needs to do the work that is in the "manager"
CFC now. However, if that thing is a CFC then the problem doesn't seem to be
solvable. This is especially true since the application in question is
Mach-II based thus requiring the logic in CFCs.
I have thought about creating the "manager" object in Java to get around
this problem, but that is less than ideal.
-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]
