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.

About Jeremy Miller

Jeremy is the Chief Software Architect at Dovetail Software, the coolest ISV in Austin. 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 is the author of the open source StructureMap tool for Dependency Injection with .Net, StoryTeller for supercharged acceptance testing in .Net, and one of the principal developers behind FubuMVC. Jeremy's thoughts on all things software can be found at The Shade Tree Developer at http://codebetter.com/jeremymiller.
This entry was posted in Database and Persistence, Ranting. Bookmark the permalink. Follow any comments here with the RSS feed for this post.