Friendly Debate over Application Configuration

Question

My perspective is clouded by my line of work (enterprise applications) but a lot of the applications I work with are HEAVILY configuration driven. When they were originally built the standard practice was the app.config. There are 2-3 competitors in this field and I have worked with all of them. These apps cross multiple business domains from the front to the back office. That means that there are literally hundreds of configs for everything from data connections to report definitions to key connections between tables/entities. That ends up being a nightmare to maintain when doing customization and implementation or migrations. Afterwards, it ends up being reasonably static and will "just work".I still think its clunky, and am curious what other folks do for highly configurable applications that require a lot of configuration. I think that aside from the bare necessities to stand up an environment, a database is a great way to store and maintain configuration. I dont think its without flaws or drawbacks, but the number of times I have to debug "the given key is already in the dictionary" error messages (which by default the .NET framework wont even tell you what key that is) when a database could immediately spit out that an insert failed due to constraint failures with the values is so much more convenient. What are some better practices to configure apps?

stmw · Accepted Answer

Without getting into the details of the specific technology (app.config, etc.), I would argue that config should go into files instead of databases. For all the problems with poorly-structured file-based application configuration that OP points out, the same practices but using a database lead to far worse consequences. One important advantage of files is that their lifecycle can be managed separately from user application data (which tends to be in the database) and potentially even be put under source control.