3 ms·
I think they want to use something more like an environment contextual config fetcher instead. For example: test.appsettings.json {"db-url":"test.url.here"}
by didibus 6y ago
I think they want to use something more like an environment contextual config fetcher instead.
For example:
test.appsettings.json
{"db-url":"test.url.here"}
prod.appsettings.json
{"db-url":"prod.url.here"}
Now in the code:
Settings.fetch("db-url");
// Will return the test one if environment variable says we are running under test environment, else will return the prod one.
- WorldMaker 6y agoThe DI-based configuration system can be configured to do exactly that. Though yes, the configuration is maybe harder than it should be simply because it isn't on by default. A lot of the complexity in the configuration system exists to enable a lot of configuration options. I have some ASP.NET applications that get some configuration from Environment Variables on the host machine, some from environment-specific config files, some from a configuration service (specifically Azure Key Vault), all without any of my DI-injected downstream components specifically needing to know which source provided specifically which configuration key. For the DI injected things it is just `config["db-url"]` or maybe type-safe class if I DI-inject an IOptions<T> (or add my type-safe classes directly to the DI without the IOptions<T> wrapper, which is another configurable option). It's absolutely a very complex system, but with great complexity comes great flexibility (to badly paraphrase the Spider-Man mantra).