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]


Reply via email to