Question

We have lot of application parameters for each module in a C# .NET 4 ASP website.

parameter examples: timeouts, formulae constants, thread limits per module, $ charges per usage etc.

What is best out of following approaches we know:

1. Use DB config table
2. Use an xml. load that xml into local cache on start (and on xml change)
3. simple constants.cs file with public const int XYZ = 123; type of key-value pairs.
4. web.config (though i think its mostly for deployment type of config)
5. Any other way ?

Help on pros and cons and std. approach followed would be helpful.

Answer 1

I like #1, storing the values in the database, for several reasons:

1. This works on a web farm. You don’t have to synchronize versions of web.config on multiple servers.
2. Making changes does not require recompiling and redeploying the application. Changes can be immediate.
3. It is relatively easy to create a maintenance web page for authorized users to update the values without bugging production support.
4. The values can be determined at any time from outside the application by anybody given access to the database (or to a maintenance page displaying the values). Nobody has to read through the source code or look at web.config files.
5. The web application does not have to be restarted for the change to take effect.

Edit: Additional comments about the other proposed methods:
If the app is going to be on a web farm, all three non-database choices will require deployment to all servers. This is not a trivial matter if a lot of web servers are involved, if the deployment procedure is complicated, or if corporate policy severely limits who (and when) changes can be deployed to production servers.

Even when there is no web farm, in a corporate production environment, it can be excruciatingly slow to deploy a change.

Regarding constants, I have found that they tend to get sprinkled all over the application code. Finding them can be a real challenge. Of course, if you have the discipline to centralize the configuration constants, you won’t have this problem.

There is one other approach not on your list, which is using resource files (.resx). While this is generally used for localization, I have seen it used for configuration values, and especially for storing the text of standard messages. While you don’t have to recompile your application to alter a .resx file, changing it will cause the application to restart.

In summary, then, my reasons for preferring the database approach are the speed and ease of deployment, avoiding recompilations and app restarts, centralizing the data outside the application, and making the data accessible to business users.