Application Settings in MVC5 Web App - Using C# class vs Web.Config?

Question

I'm building out my application and I'm at a point where I've hardcoded a lot of settings at the top of my class files - stuff like ApiSid and ApiKey , SmtpServiceUsername , MyEmailPassword etc. I'm now trying to consolidate these and I see two options:

1) Push them all into web.config . I don't like the thought of muddling up my web.config with tens (almost 100) settings though... I also feel uncomfortable with security here.
2) Build a static class that just contains these settings (Settings.cs) - basically housing a bunch of constants that are referenced throughout the app.

I feel more comfortable with the second approach because I can keep my settings totally isolated and not worry about exposing them via web.config - is there anything inherently wrong with this approach?

Answer 1

This is not necessarily the best approach but I'd store these kind of settings in the database. This gives you database security for the settings plus it's easy to update the settings without having to stop / restart the application so you avoid kicking out users.

Once you have your settings in the database, you can load them periodically (like every 15-20 minutes) to detect changes. In the meantime, create a dictionary of the data and either wrap it in a class that provides type-safe access through properties or just use the dictionary directly. Since this is web application, you'll have to use a thread-safe class (like ConcurrentDictionary ) to make sure multiple threads can safely access your settings.

If you have so many settings, web.config would be cluttered and every change would force an app pool restart. As @David mentions in his answer, the config file gives you an easy way to have different settings for different environments but this is also easy to do with a database approach where settings may be present once per environment.

Answer 2

is there anything inherently wrong with this approach?

1. What makes you think putting constants in the code is any more secure than in the config? The compiled DLLs are right there next to the Web.Config , if somebody can examine one of them they can examine the other one. Hard-coded values can be de-compiled pretty easily.

2. Config files exist for a reason. Specifically, if any value is going to change per environment then it belongs in the config file. That way the same identical codebase can be used in any environment (development, test, production, etc.) and you'd just edit the config values for that environment. Having to re-compile the code just to deploy the same version to a new environment is less than ideal, since it's no longer the same version.

   I don't like the thought of muddling up my web.config with tens (almost 100) settings though

Why not? If they're all flat static values, a list of appSettings keys would be fine. If there's more structure to them, create custom config sections .