Hi,
this is all great stuff. Exactly what i am involved with now Matt, a large
Mach-ii app that I am trying to use with a number of 'singleton' cfc
instances.
My current approach:
1. load an EnvironmentManger object into the server scope (it is configured
via xml). I do this because we run side by side versions of the same
application on the same server that may have different settings (ie
different database, logging directories, debugging settings etc) and a
different cvs build
<cfparam name="server.EnvironmentManager" default="">
<cfif not isObject(server.EnvironmentManager) OR
listFindNoCase(local.lRefresh, "server")>
<cfset Server.EnvironmentManager = createObject("component",
"SSubmit.environment.EnvironmentManager").init()>
<cfset Server.EnvironmentManager.configure(CGI.LOCAL_ADDR)>
</cfif>
<cfset local.InstanceDIR =
lcase(GetDirectoryFromPath(GetCurrentTemplatePath()))>
<cfset Server.EnvironmentManager.connectApplication(local.InstanceDIR,
local.lRefresh)>
the environment manager is responsible for connecting each request to the
correct/current cfapplication, it also initialises the application/session
scopes, and sets any request based values (perhaps an overriden database) as
determined by url parameters,cookies etc
in addition on initialisation of the application it
1. loads an ApplicationContext object into application scope (a facade to
properties which may come various scopes and can easily be mocked)
2. loads a ComponentBroker object into application scope (and injects the
applicationcontext object via 'setter injection')
The ComponentBroker is now responsible for the creation of all cfcs. cfcs
are requested via aliases (the Component broker is configured by a xml file,
that maintains the paths to the cfc). It also configures whether component
is 'static', 'singleton' (application or session) and handles simple
caching/pooling of instances. It injects the applicationContext into each
component it creates (as well as a reference to itself ) via common setters
(read 'human compiler enforced interface'). Objects that rely on other
objects can have these objects created and passed in (xml file configures
these dependencies). Implementation injection i think this is called.
The ComponentBroker can preload all static/application singletons at start
up or as requested.
So that mach-ii is loosely coupled with all this I use a plugin to create a
reference to the component broker and put it in the property manager.
for testing i just instantiate an ApplicationContext object that is
uncoupled from cfapplication etc and a ComponentBroker Object if required
example of testing without machii framework
<!--- set enough variables for applicationcontext to provide needed values
for DAO operations --->
<cfset request.stDatasource = structNew()>
<cfset request.stDatasource.dbtype = "oracle">
<cfset request.stDatasource.dsn = "development">
<cfset request.stDatasource.username = "****">
<cfset request.stDatasource.password = "****">
<cfset ApplicationContext = createObject("component",
"SSubmit.environment.ApplicationContext").init()>
<!--- via broker --->
<cfset ComponentBroker = createObject("component",
"SSubmit.model.ComponentBroker").init()>
<cfset ComponentBroker.setApplicationContext(ApplicationContext)>
<cfset ComponentBroker.configure(false)>
<cfset DAOFactory = ComponentBroker.getInstance(alias='DAOFactory')>
<!--- OR direct--->
<cfset DAOFactory = createObject("component",
"SSubmit.model.dao.DAOFactory").init()>
<cfset DAOFactory.setApplicationContext(ApplicationContext)>
<!--- DAO factory is a kind of ComponentBroker too--->
<cfset var AttachmentDAO = DAOFactory.getDAO("AttachmentDAO")>
<cfset qAttachment = AttachmentDAO.createAttachment(3, "Some Description",
2000, 0, "somefile.pdf", "", "12345678.pdf")>
Any comments, criticisms, thoughts appreciated
Elliot
On Mon, 6 Sep 2004 11:08:40 -0400, Matt Liotta <[EMAIL PROTECTED]> wrote:
> 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]
