When writing software, you will come across many questions which don’t always have a clear answer, and its tempting to not answer the question, and provide it as a configuration option to the user of your software. You might go as far as setting a default value though. This seems good for everyone; you don’t have to make a decision, users can change their minds whenever they want. However, too much configuration is a bad thing in general....
After my previous post on Validating Your Configuration, one of my colleagues made an interesting point, paraphrasing: I want to know if the configuration is valid earlier than that. At build time preferably. I don’t want my service to not start if part of it is invalid. There are two points here, namely when to validate, and what to do with the results of validation. Handling Validation Results If your configuration is invalid, you’d think the service should fail to start, as it might be configured in a dangerous manner....
As I have written many times before, your application’s configuration should be strongly typed and validated that it loads correctly at startup. This means not only that the source values (typically all represented as strings) can be converted to the target types (int, Uri, TimeSpan etc) but that the values are semantically valid too. For example, if you have a web.config file with the following AppSetting, and a configuration class to go with it:...
It’s no secret I am a fan of strong typing - not only do I talk and blog about it a lot, but I also have a library called Stronk which provides strong typed configuration for non dotnet core projects. The problem I come across often is large configurations. For example, given the following project structure (3 applications, all reference the Domain project): DemoService `-- src |-- Domain | |-- Domain....
As anyone I work with can attest, I a have been prattling on about strong typing everything for quite a while. One of the places I feel people don’t utilise strong typing enough is in application configuration. This manifests in a number of problems in a codebase. The Problems The first problem is when nothing at all is done about it, and you end up with code spattered with this:...