CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Jeremy D. Miller -- The Shade Tree Developer

Under the hood and working with .Net, TDD, Software Design, and Agile Stuff

Exposing a Connection String as a Public Property is a Huge Design Smell

Pure diatribe ahead:

Take a look at this code and ignore any concerns over security just at the moment:

	public class MyConfiguration
	{
		public static string ConnectionString
		{
			get
			{
				// lookup the connection string wherever it is
				string connectionString = lookupValue("CONNECTION_STRING");
				return connectionString;
			}
		}

		private static string lookupValue(string key)
		{
			...
		}
	}

This little piece of code may seem innocuous.  It's just a little static helper class to look up the database connection string.  Remember the scene in Lost Boys when the head vampire mocks the heroes by telling them that "Don't ever invite a vampire into your house, you silly boy. It renders you powerless."  Exposing the connection string to any and all callers in a system can effectively denude your system of the protections inherent with layering.  You have probably lost any hope of a coherent data access strategy.  It doesn't *have* to be this way, but every time I've seen (or written) a system that had a publicly available connection string property, the result is pure chaos.  People will grab the connection string and write tons of one-off data access code anywhere and anyhow that they please.  Of course, some of my irritation is that the code I'm looking at uses a modified version of the original DAAB -- one of the stinkiest pieces of code ever dumped on us by Microsoft.

The database connection string should only be used by a small handful of classes dedicated to data access so you can centralize the database access code

The dumbest example I've ever seen was a proto-SOAP framework our enterprise architects rammed down our throats that forced us to push a connection string down from the service layer to the business layer and finally down to the data access code.  All so we could write a couple hundred lines of scaffolding code to use his pet framework instead of the "complex" 3-5 lines of code it used to require to pull an Xml document off of an HTTP POST request in ASP/VB6.  Using this web service framework was also going to require us to make 3 HTTP posts on every call (including a pair of self-posts!) and at least a couple of DCOM round trips.  We timed a no-op call at 3/4 of a second -- for a system that was under a heavy load.  My hatred of non-coding or centralized architects started with this project.  My time as the central architect only reinforced this view.



Comments

Fregas said:

Dude thats painful.

I think architects should ALWAYS be coding to keep their skills up, so they know wtf their talking about and have ownership of the code on top of their frameworks.

I too used to put the connectionstring somewhere accessible by the presentation layer but i'm moving it more and more to the data access like you said, for centralization. I have code very similar to what you have above, but I moved out of the web layer and into the DAL.
# September 28, 2005 11:31 AM

Harris said:

Jeremy,

Just curious then, how do you store your connection string in your applications? I'm not defending this code, however, it seems to just make good sense to place the ConnStr in the [web|app].config so that you only have to change it one place.

Do you typically embed the connection string in an XML file as a resource in the DAL assembly, similar to NHibernate mappings?

Thanks,
# September 28, 2005 1:33 PM

Jeremy D. Miller said:

Harris,

My preference is to use windows authentication for the database connection (I've always been told this is possible in Oracle, too) and store in a configuration file. I use StructureMap for all configuration, but I think the real goal is to just keep as close to XCopy deployment as you can. Some shops insist on encrypting it somewhere, usually in the registry, for security. It might be a case of security vs. convenience.
# September 28, 2005 2:17 PM

Charlie said:

Hi Jeremy,

I had a look at the sample linked.

Unless I'm mistaken, you need to keep a connection open for as long as you are using a IDataReader? Your code doesn't seem to cope with this... any recommendations for this situation?

thanks

// charlie
# September 28, 2005 6:17 PM

Jeffrey Palermo said:

Jeremy highlights some foobar code that exposed a connection string to a database via a public static...
# September 28, 2005 11:45 PM

Jeremy D. Miller said:

Charlie,

You are correct in that you have to manually close the IDataReader. I'd say you *always* get the IDataReader inside a using block like this:

using (IDataReader reader = session.ExecuteReader(sql))
{
// do stuff
}

Database connection hygiene has to be understood by every developer that touches the database. Eliminating the "did I remember to close every single datareader and connection" issue is one reason why I'm leaning towards getting out of the ADO.Net game and just using NHibernate for new data access work.
# September 29, 2005 6:29 PM

Harris said:

Jeremy,

Completely agree. XCopy deploy is the ultimate goal. However, Windows Authentication can be a nightmare to configure. I realize that might sound ubsurd, but take a look at Keith Brown’s latest column[1] in the MSDN on Impersonation and Delegation. It gets really, really ugly when your database is sitting on another machine than where your app is.

Generally, my gut tells me it would be best to encrypt the connection strings if they aren’t using an integrated authentication and authorization approach. While I do agree with you that “it becomes a case of security versus convenience”, how many times does convenience come back to haunt even the most “senior” developer?

My team, also, is trying to move to NHibernate for all its future projects. Personally, I think best approach may be to keep the configuration files in a NHibernate CFG resource file and use DotFuscator to mangle some of that information. At least, with this approach, you can mock or stub-out reading the information from the resource files…

Anyway…thanks for the great post!

[1] http://msdn.microsoft.com/msdnmag/issues/05/09/SecurityBriefs/
# September 30, 2005 9:37 AM

vorpal.cc » First Post said:

# April 16, 2006 4:27 PM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add

About Jeremy D. Miller

Jeremy began his IT career writing "Shadow IT" applications to automate his engineering documentation, then wandered into software development because it looked like more fun. Jeremy previously worked as a systems architect building mission critical supply chain software for a Fortune 100 company and learned agile development practices as a .Net consultant at ThoughtWorks, one of the pioneers of agile development. Jeremy is the author of the open source StructureMap (http://structuremap.sourceforge.net) tool for Dependency Injection with .Net and the forthcoming StoryTeller (http://storyteller.tigris.org) tool for supercharged FIT testing in .Net. Jeremy's thoughts on just about everything software related can be found on his weblog "The Shade Tree Developer" at http://codebetter.com/blogs/jeremy.miller, part of the popular CodeBetter site. Jeremy is a Microsoft MVP for C#. Check out Devlicio.us!

Our Sponsors

Free Tech Publications

This Blog

Syndication

News

All opinions expressed here constitute my (Jeremy D. Miller's) personal opinion, and do not necessarily represent the opinion of any other organization or person, including (but not limited to) my fellow employees, my employer, its clients or their agents.

About Me

"Best Of" Compendium

StructureMap (Dependency Injection for .Net)

StoryTeller (Supercharged Fit)

Build your own Cab

TestDriven

MVP