Reason for emphasizing programmatic configuration for library components

Topics: General discussion
Nov 26, 2014 at 6:16 AM
Hi !,

I understand why EntLib team would add new configuration approaches. But I am curious towards why would you emphasize the programmatic approach towards configuration?
With Declarative (XML) based configuration we could edit file and get he library component behave accordingly.
Now with programmatic approach such a change would mean changing the version numbers (increment)?

Please guide my thoughts..
Nov 28, 2014 at 5:48 AM
The preferred configuration approach is a programmatic based approach. However, the declarative XML based approach is still supported and, if you find that suits your needs better, feel free to use it.

You mention the main use case for declarative XML configuration: you can change the behavior at runtime by editing a configuration file. This is definitely flexible but is it really good thing? For non-functional behavior I can definitely see this as being valuable. The classic example is logging -- e.g. you want to increase the minimum severity to gather more information in response to a production-issue. However, for "functional behavior" it can be dangerous to expose the "application logic" via configuration.

Do we really want to change our exception handling policies "on the fly"? Swallowing exceptions (instead of throwing) would most likely break the application (or result in strange behavior and executing code paths that have not been tested).

Or do we want to change our validation rules at runtime? Maybe we do but, once again, it would be prudent to test these changes using a similar release process to a change to compiled code.

In my own experience, I have seen many instances of production applications being "broken" due to XML misconfiguration.

Back to logging for a minute: the current programmatic approach does support reconfiguration at runtime so the logging block does address this use case.

The declarative approach also involves XML configuration that can be arcane and hard to author. So much so that an external tool was developed just to facilitate generation and editing of the XML configuration.

Other things to consider are unit testing; it is usually easier to have all of the test logic contained in code as opposed to depending on managing and deploying external files.

In terms of versioning, if you follow Semantic Versioning then a change to functionality would result in a different version number (depending on the type of change).

Of course, there are no silver bullets or one size fits all solutions. For example, an off the shelf application or hosted application that requires/allows custom configuration by the end user/IT Professional might be a good candidate for externalized declarative XML configuration (of course there are other designs and approaches to support those requirements as well).

If declarative XML configuration is a good fit for you then use it. :)

Randy Levy
Enterprise Library support engineer
Support How-to