This is umm actually a bad idea in my book (if you are using an OO CFC based method of attack that is)
Context gives your application Persist Scope, meaning your Application can one day use XML as its storage, then the next it could use SQL.
What happens if you store information within Multiple DSN's? Audit Information goes in DSNA, while mainstream Data goes into DSNB (why? seperation of security for one).
I've built / used a config business object, and I pass that into all of my "Services/Managers/Herders/Builder" classes. This configuration object initializes itself based on an XML packet that I "couple" with the application. Now, at this point i don't simply have routines "getDSN()" for example.
I class my overall DSN information based on the persist service they provide, meaning i have a method within my config which is like: "getPersistService('security')" which depending on the DB Server type, returns appropriate DSN information.
Another classic mistake is folks sometimes use username + password, while other times they don't (ie shared hosting, its a must. Dedicated hosting, not so much).
Point is this, the only points of customization within my cf applications are:
- DAO_SQL, DAO_Oracle, DG_SQL, DG_Oracle etc..
The rest of the business logic doesn't give two hoots. The main reason for this is simply that while Application.cfc is great, its easily abused and in a nutshell Application.cfm is probably the best suited aspect of a coldfusion application which provides appropriate context to its intended use, resulting in promoting a better "re-use" capability within your code.
If i had to pick this setting, i'd much prefer Barneys approach whereby we leveridge some kind of Mapping/Alias to suite our CFQUERY code. To me thats a much easier and more elegant approach.