On debuggable configurations
time to read 12 min | 2250 words

Tomer Gabel commented on my post about debuggable configuration:

This may be debuggable, but it sure as hell doesn't look like configuration to me. Configuration should be declarative and should not contain complex logic (what you show above definitely falls under that category in my book). This sort of script is, as far as I'm concerned, tantamount to collating all your configurable properties into one external, dynamically-compiled class -- in other words, hardcoded.

Let me just point out what I tried to do when I started using this approach:

death.by.xml.png

Looks familiar, anyone? I have shown this image to a fair amount of people, I got a lot of guilty looks :-) and general acknowledgement that this is a very bad place to be.

Now, to Tomer's comment:

This is a dynamically compiled class, but I wouldn't call it hard coded. It has all the features of a configuration file, i.e: restart the app and it will get the chances, I even has an app when I can do this type of changes on the fly. Declarative is an issue because you start to get out of control very fast with it in even mildly complex scenarios.

When I need to change a property or a feature, I can do so by opening this in notepad, make a change, and continue, there is nothing else that is needed to happen. I routinely does such things on production (tuning parameters, etc). I believe that this approach is far more common in dynamic langauges. Configuring MediaWiki, for instnace, is done by editing a php file.

This simplify things to a large degree, no need to extract values form XML, build the object graph, transform it, etc. I can just build the final result directly. The code I have shown is also doing some glue to connect some parts of the application. I mentioned that I am not sure if it is the responsability of the configuration to do so, but that is another matter.

Where does XML configuration fails?

Repeated configuration, I need to define 10 things of the same kind, with slight variations. For instance, defining a customer, where each customer has a different connection string:

customersDatabases = {

      "Northwind"       : "Data Source=...",

      "AdventureWorks"  : "Data Source=..."

      }

     

for entry in customersDatabases:

      Application.RegisterClientDatabase(entry.Key, entry.Value, ClientOptions.UseSharedConfiguration)

Now, imagine trying to do that in XML. Specifying debug/release configuration is also much easier:

if Environment.MachineName ~= /prod/: #production

      Application.LogLevel = LogLevel.Error

      Application.CrashReport = ( EmailReport("admin@site.com"), SmsReport("132432142") )

      Application.ShowErrorToUser = false

     

if Environment.MachineName ~= /test/: # test / staging

      Application.LogLevel = LogLevel.Info

      Application.CrashReport = ( BugTrackReport("trac.build.com"), )

      Application.ShowErrorToUser = false

     

if Environment.MachineName ~= /lap/: # dev machine

      Application.LogLevel = LogLevel.Debug

      Application.CrashReport = ( ErrorMessageReport("trac.build.com"), )

      Application.ShowErrorToUser = false

Trying to do the same in XML bring you right back to trying to debug XML. Since I don't know anyone except developer / IT admin that is going to touch a configuration file anyway, the claim that it is not readable to non-dev is not an issue. It is worth mentioning, though, that it is fairly easy to build a GUI over this.

Tweet Share Share 0 comments
Tags: