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

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.