0 comments
.NET 
Sometimes XML configuration can be really cumbersome, you need a ton of .config files and .xml files to even get a small application running. It seems as if the xml fetish has come to a point that people start to get annoyed and start looking for alternatives.
Use of configuration files in practice
Before I start talking about how I think configuration can be approached, I’d like to show some examples from the industry on how configuration files are used and what alternatives the industry is providing today.
For example NHibernate uses NHibernate mapping files to map classes to tables in the database. You need one file per class, so when you build a decent sized application this will soon get to at least 20 – 60 files. Alternatively you can make the configuration in code using Fluent NHibernate, which eliminates the need for XML configuration entirely. Note though that this doesn’t solve the problem of having to specify the mapping for all those classes in some way.
Then there is CompositeWPF, there you can choose to use the XML module enumerator class for configuring which modules should be made available in the application, however this requires you to write a ton of XML to get the modules configured, with all the risks of not getting the application working. Alternatively you can use the Directory module enumerator and be done in a jiffy.
A very good example of how you can setup configuration from code in my opinion is Unity. The configuration is done from code, so users can’t mess up the internal workings of the application. One really disturbing note however is that you can influence this configuration using a special configuration section in the app.config file.
General toughts
In general I think that using XML for configuration isn’t a bad thing, however it can get out of hand. The worst example of this is stuff that shouldn’t be visible to the user, because it’s configuration needed for a framework that is strictly meant to make life easier for the developer. Configuration for these kind of components should generally be in code. The reason for this is simple: The developer is used to working with code and moreover, you get free compile time checks if the API for configuring the framework was written correctly. The end result of this is higher quality software and less frustrated users.
There is a category of configuration data that changes more often and should be accessible to the user who deploys the software and uses the software on a dayly basis. Some of the settings that should be editable by the user can well be placed inside XML files or .config files. A database connection string that is configured only once for example should belong inside a .config file and should be updatable when required. In this case XML is great, because system administrators almost immidiately understand the format and can start editing the config file without having to decode complex constructions.
Last but not least, there’s a category of settings that should be easily accessable through the user interface. The user should be able to change these settings without restarting the application. I think it’s rather frustrating having to close the application before I can update something simple like the path of a project file I’m working on.
Final thoughts
Like the voiceover on animal planet ssay: Please do give a thought where you configuration goes (Err.. I think she meant rubbish). It will make your application not only more maintainable, but also prevents users from making mistakes that they shouldn’t be possible to make in the first place.