Where should connection strings be stored in a n-tier asp.net application

Question

Folks,

I have an ASP.NET project which is pretty n-tier, by namespace, but I need to separate into three projects: Data Layer, Middle Tier and Front End.

I am doing this because...

A) It seems the right thing to do, and

B) I am having all sorts of problems running unit tests for ASP.NET hosted assemblies.

Anyway, my question is, where do you keep your config info?

Right now, for example, my middle tier classes (which uses Linq to SQL) automatically pull their connection string information from the web.config when instantiating a new data context.

If my data layer is in another project can/should it be using the web.config for configuration info?

If so, how will a unit test, (typically in a separate assembly) provide soch configuration info?

Thank you for your time!

Answer 1

For testing purposes don't instantiate DataContext with default ctor. Pass connection string info to constructor.

I prefer to use IoC frameworks to inject connection to data context then inject context to other classes.

Answer 2

We keep them in a global "Settings" file which happens to be XML. This file contains all the GLOBAL settings, one of which is a connection string pointing to the appropriate server as well as username and password. Then, when my applications consume it, they put the specific catalog (database) they need in the connection string.

We have a version of the file for each operating environment (prod, dev, staging, etc). Then, with two settings -- file path (with a token representing the environment) and the environment -- I can pick up the correct settings files.

This also has the nice benefit of a 30 second failover. Simple change the server name in the settings file and restart the applications (web) and you have failed over (of course you have to restore your data if necessary).

Then when the application starts, we write the correct connection string to the web.config file (if it is different). With this, we can change a website from DEV to PROD by changing one appSettings value.

Answer 3

As long as there isn't too much, it's convenient to have it in the web.config. Of course, your DAL should have absolutely no clue that it comes from there.

A good option is for your data layer to be given its config information when it is called upon to do something, and it will be called upon to do something when a web call comes in. Go ahead and put the information in your web.config. In my current project, I have a static dictionary of connection strings in my data layer, which I fill out like so in a routine called from my global.asax:

CAPPData.ConnectionStrings(DatabaseName.Foo) = 
    ConfigurationManager.ConnectionStrings("FooConnStr").ConnectionString()
CAPPData.ConnectionStrings(DatabaseName.Bar) = 
    ConfigurationManager.ConnectionStrings("BarConnStr").ConnectionString()
etc.

"Injecting" it like this can be good for automated testing purposes, depending on how/if you test your DAL. For me, it's just because I didn't want to make a separate configuration file.