Why not put them in application scope in onApplicationStart() and later reference them as application vars?
Since these variables contain constants, I don't see race condition an issue here. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Cody Caughlan Sent: Wednesday, March 22, 2006 9:53 AM To: [email protected] Subject: [CFCDev] Storing DSN parameters in a "global" variable 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]
