Recently I’ve been building out something that is very configurable. Tons of different settings, switches, numbers… you name it. Its nice to have things split out into areas of concern – that is, different interfaces identifying the configuration settings pertinent to a particular thing – but then you end up with all of these things floating around.
At the end of the day, all of my configuration settings are going to be stored in one object in a MongoDB document. So, when I read the document once, I want to be able to disseminate the appropriate cross-sections of configuration information into its appropriate interface.
I ended up creating a “ConfigurationService” which, in its interface, lists the other configuration interfaces. The implementation is pretty straightforward:
Note: The key is that reading the configuration from the database needs to happen in the constructor so that all of the properties will be populated when someone (AutoFac) comes to read it.
Then, where you build up your AutoFac container:
AutoFac will resolve the IConfigurationService, pull the appropriate property, and register that as the interface. This means when it comes to actually using one of the configuration interfaces, you simply inject it as you would any other interface. Keeps things neat and tidy, giving you only the configuration properties that you care about.
Automatically registering properties as implementations in AutoFac – Darchuk.NET
[…] this post I talked about building out a configuration service that could be split into various areas of […]