How to dynamically configure an application?

Question

When I say "configure" I mean where to save those values that could change very often (constants values like taxes rates or something similar) and then when you need to change them you don't want to re-compile your application.

Where to save those values? Database? XML File? Flat File?

Answer 1

I use INI files for potentially user-configurable files, and BIN files for data that save session state between runs.

But, it is very dependent upon what type of application you are developing.

Answer 2

it depends on how your app is architecture. you could design your app in such way that you could change the location of you configuration. by just injecting the provider.

Answer 3

It depends on how often these change and who or what changes them. For some application specific settings, it's best to use an XML or config file, where the developers are the ones responsible for updating it. For other "businessy" values (like exchange rates, tax rates, etc), it's best to keep them in the database and provide a UI for users (not developers) to update.

It also depends on how many apps depend on this value, for example, if several applications depend on some setting (such as email server addres), it's best to put it in a database since it'll be easily accessible from any machine where the app is running.

Answer 4

Normally I use Ini files or XML if the data is structured.

For applications that already use a database and you don't want to have the user to change the data easily, you can use the database.

I almost never use binary data unless you want to obfuscate the data for the user.

Answer 5

Regardless of app, you're probably going to have at least 3 sources of configuration data:

1. Command line flags, usually for bootstrapping your run-time environment, e.g, finding config files, setting debug flags, include paths, class paths, etc
2. Config files, potentially more than one that may override each other. These usually boot strap your application: connection strings, cache settings, build-specific settings, etc
3. Control data in a database. Things like timezones, conversion rates, stable display values, etc. This data should also be versioned in the database (as in, a "Data Version" field, not living in a version control system). Versioning it will save a lot of headaches when you find you need to change a setting for a new release, but the old release will break if you change it.

Generally, anything that changes at run-time should go in the database. Anything that is sensitive and rarely changing should go into the config files, and any hacks should go on the command line (--[no]enable-bug-287438-hack can be very handy when you need it).

Answer 6

I prefer the simplicity of a flat ini file. Here's an example Setting class that you might find useful.