3 ms·
I'm mainly interested in one statement: > it's just pointless boilerplate trash, which C# has been getting rid of excellently Could you elaborate on how you f
by fuzzy2 6y ago
I'm mainly interested in one statement:
> it's just pointless boilerplate trash, which C# has been getting rid of excellently
Could you elaborate on how you feel C# avoided this?
From my point of view the only alternative (to DI with constructor injection) is static members somewhere, which does not scale. Maybe property injection, but ugh.
- didibus 6y agoI 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).