Even for a strong believer in convention over configuration like myself, there always will be the need of configuration parameters to be stored for any number of non-trivial applications. Like most things enterprise, the debate for configuration store and its management depends on the various factors including the environment, deployment methodology and type of configuration elements. Keeping registry keys out of picture (yes, welcome to 2012), let’s discuss the some pros and cons for each of the config store.
|
Config File |
Database |
| For values which cannot be retrieved before database is accessible or immediately need to be accessible upon application start such as database connection strings.Environment initialization related information;In most modern frameworks, file system watcher supports application restarts upon config change.
Frequently changing values for a non-distributed application.
Ease of version control, replication and distribution.
Editing can be potentially risky and erroneous. Not suitable for multiple environments due to consistency issues.
Environment specific settings (with shared commonalities) become a deployment with config files.
|
Ideal for synchronizing distributed environments and multiple nodes in the cluster with similar settings.In high availability scenarios (such as appfabric HA mode requires SQL server to be used for configuration purposes).
When changing parameters in a clustered environment, one database update would make changes available across the environment.
The applications need to have a polling mechanism to monitor the change such as SQL notifications and to efficiently cache these values in memory with eviction policy in place.
As compared to config files, a more user friendly UI can be built relatively easily to modify the parameters.
Multiple versions may require different key values.
|
The bottom line is that if it’s a large scale distributed environment, database is the way to go unless you have automated config file management system in place. Keep light-weight config files which rarely change for essentials such as environment-info service to retrieve connection strings or session parameters. For performance, simplicity and ease of use in homogenous non-clustered single server deployments, config files should still do.
