Encapsulate application wide settings in an application scoped
singleton, and instantiate all my CFC's within a Factory (which is also
an application scoped singleton).
When the Factory is instantiated, appSettings is passed in and placed in
Factory's variable scope. Then from there, it's a very easy
modification, either to appSettings, or to the Factory, if i find that i
need an an application wide setting somewhere in the app. Either i
modify appSettings if it's not present there yet with the appropriate
getters/setters and variables, or i modify the Factory to pass a
reference to appSettings into an object that needs an appSetting.
So the combination of encapsulating application wide settings and
encapsulating object instantiation in a factory makes handling future
modifications very easy and painless.
:) Nando
Mark Ireland wrote:
OK Nando. So what do you do instead?
From: Nando <[EMAIL PROTECTED]>
Reply-To: [email protected]
To: [email protected]
Subject: Re: [CFCDev] Storing DSN parameters in a "global" variable
Date: Wed, 22 Mar 2006 21:01:27 +0100
I guess the "right" answer is experience.
Once you start to really "get" how well object oriented principles
work, setting request scoped variables that you're going to reference
in your CFC's starts to seem like a really hare-brained idea.
Who would ever do such a thing?!
And yet, when i first started experimenting with OO, that's exactly
what i did. Why? Because i didn't understand enough about OO
application design to know how to do it any differently.
Cody Caughlan wrote:
Is there anything inherently wrong with storing your DSN parameters
in a
Request-scoped structure and referring to these in your cfquerys, e.g.:
<!--- pseudo-code --->
App.cfc::onRequestStart() {
Request.DSU = "myDBUser";
Request.DSP = "myDBPassword";
Request.DSN = "myDSN";
Request.DST = "ODBC";
}
.... later, in some code deep in your app...
<cfquery name="foobar" datasource="#Request.DSN#"
username="#Request.DSU#"
password="#Request.DSP" type="#Request.DST#">
....
</cfquery>
Apart from the encapsulation this *does not* give you, is there
anything
wrong with this? That is, your code is now tied to the Request scope. I
*know* it would be much better to pass every DSN struct into your
CFC that
needs it (possibly using some kind of a centralized object factory like
ColdSpring). I have a fellow developer who prefers this "global"
approach. I
say its bad, he says its OK, because Macromedia (now Adobe) will
never take
away the the REQUEST structure, so its not like the code will ever
break. My
argument is that its not "proper coding", his argument is the
magnitude of
convenience this affords.
Whats the right answer?
Thanks
/Cody
----------------------------------------------------------
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).
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).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
_________________________________________________________________
New year, new job – there's more than 100,00 jobs at SEEK
http://a.ninemsn.com.au/b.aspx?URL=http%3A%2F%2Fninemsn%2Eseek%2Ecom%2Eau&_t=752315885&_r=Jan05_tagline&_m=EXT
----------------------------------------------------------
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).
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).
An archive of the CFCDev list is available at
www.mail-archive.com/[email protected]
