Storing connection strings in web.config

Why do we store connection strings in web.config file? What are the benefits of doing s开发者_运维技巧o?

The web config file is used so you can reference the connection anywhere in your app. It avoids having to deal with a fairly long connection string within your application.

Here is a good article which may give you detailed information: http://articles.sitepoint.com/article/web-config-file-demystified#

There is even a wiki page for it :) (surprisingly): http://en.wikipedia.org/wiki/Web.config

If you ever move / change to a different database format the connection string setting inside of the web.config file can be changed in one place rather then digging through your entire application looking for it. This also avoids having to recompile or build an application to get the new connection string setting.

If you are wondering how to access the information from within a web.config file that can be found here:

http://msdn.microsoft.com/en-us/library/4c2kcht0(VS.85).aspx

There is also sample code right in there.

Imagine you have several classes which access your database; you can:

1. Place your connection string in every class
2. Create a constant to store that value
3. Place it inside your configuration file and to refer it

These have following characteristics:

1. Every time a connection string changes, for instance, migrating from development to production environment, you'll need to change everywhere;
2. By using a constant, you just need to change a single place. But in this case, when your string needs to be changed, you'll need to recompile it.
3. Same as above, without that recompile part. You can to develop your application and other people set that database connection to you

So, by storing a connection string into your web.config file you gain more flexibility to change that setting than other alternatives.

Reason #1
As everyone is mentioning, having the connection string in the web.config makes it easy to update/change as needed. It becomes a single source where the arguments can be easily be changed.

Reason #2
Beyond that though, IIS is configured not serve up web.config to users who request the file. If your website is,

www.mydomain.com

someone can't hit http://www.mydomain.com/web.config and scrape all your confidential settings, passwords, and so forth.

(As a side, note, IIS won't serve up files in the App_Code directory either to a user, so the web.config file isn't unique in this respect.)

Reason #3
ASP.NET automatically detects changes to configuration files and will immediately applies new settings.

More info..
MSDN has a discussion of the ASP.NET configuration system at,

http://msdn.microsoft.com/en-us/library/aa719558%28VS.71%29.aspx

What I like most about having the connection string in the web.config is when you have multiple environments that you test on. Say you have a Test server, Staging server and a Production server. Well you don't need to have code that checks which server you're on, or have to recompile different versions for each... just use the web.config to store your connection strings and that way you can have a different web.config on each server but the same web application with no hassles. You may want to Encrypt your Connection String Settings as well so they're not visible to everyone that has access to the folder.

You can reference them using the ConfigurationManager via the ConnectionStrings property.

http://msdn.microsoft.com/en-us/library/system.configuration.configurationmanager.connectionstrings.aspx

It allows the connection string to be configured by someone maintaining the site.

You don't have to re-build the application if the connection string changes. An admin can make the change and the code remains the same.