Handling configuration settings in asp.net web application

Question

I have a web application with over 200 configuration settings. These control everything from UI to Business logic.

Should these be retrieved on application startup or when they're needed?

Should they be injected with an ISettings interface when needed.

Whats your opinions?

Update: These can be switched on and off in the application so they are stored in the database. Some are per user settings, and some are application wide. Thoughts now?

Answer 1

I would retrieve it as needed. ASP.NET auto caches this data for you. It is not doing a file read each time. Try changing your web.config file while it's running and you will see that it kills all your sessions and effectively resets your app.

Don't over complicate this. The intent of these settings in the web.config was to be used for settings across the entire application that you need to access. MS has provided you with the libraries to access them and has done the work to make that process as quick as possible. Maybe if you had thousands of settings or something you might be able to find a better caching algorithm but that would be a rare case.

Spend your time on other parts of your code as there is not much to gain in changing how you access the web.config app settings.

Update: If the settings are application wide then use the web.config. If they are user specific and stored in a DB then store them in the user's session at sign in. Some people say to use cookies for user specific settings but if you know who the user is then it is much better to use the session because it prevents a large cookie from being posted back to the server with every request from that user.

Answer 2

I agree with Kelsey, don't overcomplicate things and just use the .NET framework classes for retrieving the values. Web.config is usually where you'd keep them.
I would however recommend creating a simple static class for access:

using System.Configuration // Add a reference for this... ;

public static class Config
{
  public static string DbConnection
  {
    get
    {
      return ConfigurationManager.ConnectionStrings["ConnectionString"].ConnectionString;
    }
  }

  public static string SomeValue
  {
    get 
    {
      return ConfigurationManager.AppSettings["SomeValue"].ToString();
    }
  }
}

It'll give you strongly typed values and easy access. You can also perform some kind of validation with a class like this. Very handy. And if you later decide not to use web.config, this class is easily changed to retrieve the values elsewhere.

Answer 3

Per MSDN ISettings is used for hosting settings in VS Tools -> Options. Doesn't seem like a good candidate for a web app. Typically app settings are loaded on demand using ConfiguraionManager.Appsettings["keyname"] to get the most current value of the specified key. You can always cache the setting on Application_start if you you know for sure that the value will never change while the application is alive, but the benefit of reading it every time from web.Confg using ConfigurationManager.AppSettings["keyname"] is that the ASP.NET runtime will detect changes to web.config(such as when you modify a app setting value) and give you the most current value for the key.

Answer 4

We have a lot of configuration settings, too. We store them in a central database table. On first access, we load them all from the database and store them in Cache with an absolute expiration of 1 minute. This allows us to have an in-memory copy of our configuration settings, while also allowing us to push configuration updates that we know will be applied in, at most, 1 minute.

So, it's kind of a hybrid. On the first request for a configuration setting, they are all loaded and stored in Cache. This operation is pretty light-weight, so having it happen every minute is not a big deal for us.

Your mileage may vary.