Question

There is a long running habit here where I work that the connection string lives in the web.config, a Sql Connection object is instantiated in a using block with that connection string and passed to the DataObjects constructor (via a CreateInstance Method as the constructor is private). Something like this:

using(SqlConnection conn = new SqlConnection(ConfigurationManager.ConnectionStrings['ConnectionString'].ConnectionString)) {     DataObject foo = DataObject.CreateInstance(conn);     foo.someProperty = 'some value';     foo.Insert(); } 

This all smells to me.. I don’t know. Shouldn’t the DataLayer class library be responsible for Connection objects and Connection strings? I’d be grateful to know what others are doing or any good online articles about these kind of design decisions.

Consider that the projects we work on are always Sql Server backends and that is extremely unlikely to change. So factory and provider pattern is not what I’m after. It’s more about where responsibility lies and where config settings should be managed for data layer operation.

Answer 1

I like to code the classes in my data access layer so that they have one constructor that takes an IDbConnection as a parameter, and another that takes a (connection) string.

That way the calling code can either construct its own SqlConnection and pass it in (handy for integration tests), mock an IDbConnection and pass that in (handy for unit tests) or read a connection string from a configuration file (eg web.config) and pass that in.