7 ms·

You'd want your config injected so that you can swap out configs for test harnesses for continuous integration and deployment. It's one of the mainstays of maki

You'd want your config injected so that you can swap out configs for test harnesses for continuous integration and deployment. It's one of the mainstays of making your software deployable by automation.

fearface 6y ago
You can do that just with different config files or env vars too. No need to complicate code for stuff that can be done easily differently as well.
- eropple 6y ago
 And then you realize that it's 2020 and you don't want configuration files, you want environment variables. Or, now that you've hardstuck yourself on environment variables and built all this stuff around them to set and re-set them properly between tests (now running either in multi-process, which good luck in most environments, or are just running in serial), you're using k8s and the voluming of secrets rather than exposing them as environment variables requires refactoring any code, both operational and testing, that touches them. "But wait," you say. "I'll just pass in the thing that provides that data"--and you just reinvented DI, albeit likely poorly. DI is the removal of complication when it is done correctly. (I have no opinion on whether ASP.NET Core does it correctly.)
 - deleted 6y ago
 [deleted]
 - mattmanser 6y ago
 You wouldn't be using the config at all if you're not using the config files. They're part of the default project.
 - csharptwdec19 6y ago
 > DI is the removal of complication when it is done correctly. (I have no opinion on whether ASP.NET Core does it correctly.) I do, it was done in a really weird way and I don't care for the provided DI Abstractions nor the 'Microsoft.Extensions.Configuration' namespace. To take the 'common' object used for configuration, the nuget package for IOptions<T> requires pulling in Microsoft's DI Abstraction.. That's the first sign of a smell. Config and DI can go hand in hand, but they should still be orthogonal. The further you go down the DI stack, the more you can see that it's an abstraction has a lot of tradeoffs for front-line devs in the name of using the same abstraction for the underlying framework.
 - eropple 6y ago
 For sure--that sounds real smelly. (Unless it's being used to pull in attributes that are shared between and used for wire-up, but those should then be in a separate assembly.)
 - to11mtm 6y ago
 > (Unless it's being used to pull in attributes that are shared between and used for wire-up, but those should then be in a separate assembly.) Right. It's primarily interfaces, but they are tangled. This was especially painful between Net Core 2.0 and 3.1, because moving fast and breaking things is ugly when you have tangled dependencies and everyone is trying to catch up to the breaking API changes and related nuget versioning dance.
 - rhencke 6y ago
 A better take on DI wireups in .NET: https://nblumhardt.com/2010/01/the-relationship-zoo/ https://nblumhardt.com/2010/01/the-relationship-zoo/ The gist: Relationship Adapter Type Meaning A needs a B None Dependency A needs a B at some point in the future Lazy Delayed instantiation A needs to create instances of B Func Dynamic instantiation A provides parameters of types X and Y to B Func<X,Y,B> Parameterisation A needs all the kinds of B IEnumerable Enumeration
 - deleted 6y ago
 [deleted]
 - mumblemumble 6y ago
 > DI is the removal of complication when it is done correctly. Personally, I would rephrase that as, "DI is a pattern that is designed to mitigate certain kinds of complexity when done correctly." That leaves room for two ways in which it can backfire. Doing it wrong, like you say, but also doing it in situations where you don't actually have one of the problems it's trying to solve. Cost/benefit ratios always get out of whack when there's no benefit to offset the cost.
 - eropple 6y ago
 That is a fair edit, for sure. Many systems don't need a formal DI mechanism, though should they scale to a certain human-size they'll probably invent enough of one anyway just through composition (if they don't collapse into a ball of mud).
mattmanser 6y ago
You know a better way of doing this? appsettings.Test.json Voila, different settings! I've said elsewhere, the DEFAULT should be super simple, really, really, really easy to use. No thought, no effort, just use it. If you want to go all crazy and start injecting values into your config in your unit tests, great to have that option, you should have that option. But you're the one who should be scrabbling around writing tons of extra boilerplate code, not me. But I just want to set a filepath, that's probably never going to change, but might one day. Or an email address to send a weekly summary email to. Or some settings on paging that the client might change their mind about once and I don't want to have to rebuild the project. The vast majority of config settings are just cover your ass in case you need to one day change this value. They don't need to be tested. So it not the "normal" path to need to test config values. It's not the path the vast majority of programmers need.
- sbelskie 6y ago
 I’m confused as to what you want instead of what Asp.Net core offers. Nothing is forcing you to inject configuration or to use IOptions. In most cases you don’t even need to do anything with the configuration builder because that is part of the default of how the host gets setup. You’re configuration should be automatically built from environment vars and appsettings.json. And of course you can always just access environment variables directly if you want to.
 - mattmanser 6y ago
 I think they should have done what every other framework does and make it super easy to access, like this: Env.Config("Settings:MyEasyValue"); Or: Env.Config<Settings>().MySuperEasyTypedValue; And the Dependency Injection? Sure, add some version you can DI with. But not the default. I now know how to navigate the mess they've made, but it's not time that I feel where I gained anything in my life, it was just frustrating. Here's one (of many) questions asking simple questions on how to access config values in .Net core: https://stackoverflow.com/questions/46940710/getting-value-from-appsettings-json-in-net-core https://stackoverflow.com/questions/46940710/getting-value-f... 280k views! And look at the sheer length of that answer. If you think they succeeded in making a good configuration library, we have very different definitions of success.
ByteJockey 6y ago
How is it that the big enterprise languages haven't gotten the ability to just mock imports yet? There are certain benefits to DI, but this one seems more like a lack of tooling.

fearface 6y ago

You can do that just with different config files or env vars too. No need to complicate code for stuff that can be done easily differently as well.

eropple 6y ago
And then you realize that it's 2020 and you don't want configuration files, you want environment variables. Or, now that you've hardstuck yourself on environment variables and built all this stuff around them to set and re-set them properly between tests (now running either in multi-process, which good luck in most environments, or are just running in serial), you're using k8s and the voluming of secrets rather than exposing them as environment variables requires refactoring any code, both operational and testing, that touches them. "But wait," you say. "I'll just pass in the thing that provides that data"--and you just reinvented DI, albeit likely poorly. DI is the removal of complication when it is done correctly. (I have no opinion on whether ASP.NET Core does it correctly.)
- deleted 6y ago
 [deleted]
- mattmanser 6y ago
 You wouldn't be using the config at all if you're not using the config files. They're part of the default project.
- csharptwdec19 6y ago
 > DI is the removal of complication when it is done correctly. (I have no opinion on whether ASP.NET Core does it correctly.) I do, it was done in a really weird way and I don't care for the provided DI Abstractions nor the 'Microsoft.Extensions.Configuration' namespace. To take the 'common' object used for configuration, the nuget package for IOptions<T> requires pulling in Microsoft's DI Abstraction.. That's the first sign of a smell. Config and DI can go hand in hand, but they should still be orthogonal. The further you go down the DI stack, the more you can see that it's an abstraction has a lot of tradeoffs for front-line devs in the name of using the same abstraction for the underlying framework.
 - eropple 6y ago
 For sure--that sounds real smelly. (Unless it's being used to pull in attributes that are shared between and used for wire-up, but those should then be in a separate assembly.)
 - to11mtm 6y ago
 > (Unless it's being used to pull in attributes that are shared between and used for wire-up, but those should then be in a separate assembly.) Right. It's primarily interfaces, but they are tangled. This was especially painful between Net Core 2.0 and 3.1, because moving fast and breaking things is ugly when you have tangled dependencies and everyone is trying to catch up to the breaking API changes and related nuget versioning dance.
 - rhencke 6y ago
 A better take on DI wireups in .NET: https://nblumhardt.com/2010/01/the-relationship-zoo/ https://nblumhardt.com/2010/01/the-relationship-zoo/ The gist: Relationship Adapter Type Meaning A needs a B None Dependency A needs a B at some point in the future Lazy Delayed instantiation A needs to create instances of B Func Dynamic instantiation A provides parameters of types X and Y to B Func<X,Y,B> Parameterisation A needs all the kinds of B IEnumerable Enumeration
- deleted 6y ago
 [deleted]
- mumblemumble 6y ago
 > DI is the removal of complication when it is done correctly. Personally, I would rephrase that as, "DI is a pattern that is designed to mitigate certain kinds of complexity when done correctly." That leaves room for two ways in which it can backfire. Doing it wrong, like you say, but also doing it in situations where you don't actually have one of the problems it's trying to solve. Cost/benefit ratios always get out of whack when there's no benefit to offset the cost.
 - eropple 6y ago
 That is a fair edit, for sure. Many systems don't need a formal DI mechanism, though should they scale to a certain human-size they'll probably invent enough of one anyway just through composition (if they don't collapse into a ball of mud).

mattmanser 6y ago

You know a better way of doing this? appsettings.Test.json Voila, different settings! I've said elsewhere, the DEFAULT should be super simple, really, really, really easy to use. No thought, no effort, just use it. If you want to go all crazy and start injecting values into your config in your unit tests, great to have that option, you should have that option. But you're the one who should be scrabbling around writing tons of extra boilerplate code, not me. But I just want to set a filepath, that's probably never going to change, but might one day. Or an email address to send a weekly summary email to. Or some settings on paging that the client might change their mind about once and I don't want to have to rebuild the project. The vast majority of config settings are just cover your ass in case you need to one day change this value. They don't need to be tested. So it not the "normal" path to need to test config values. It's not the path the vast majority of programmers need.

sbelskie 6y ago
I’m confused as to what you want instead of what Asp.Net core offers. Nothing is forcing you to inject configuration or to use IOptions. In most cases you don’t even need to do anything with the configuration builder because that is part of the default of how the host gets setup. You’re configuration should be automatically built from environment vars and appsettings.json. And of course you can always just access environment variables directly if you want to.
- mattmanser 6y ago
 I think they should have done what every other framework does and make it super easy to access, like this: Env.Config("Settings:MyEasyValue"); Or: Env.Config<Settings>().MySuperEasyTypedValue; And the Dependency Injection? Sure, add some version you can DI with. But not the default. I now know how to navigate the mess they've made, but it's not time that I feel where I gained anything in my life, it was just frustrating. Here's one (of many) questions asking simple questions on how to access config values in .Net core: https://stackoverflow.com/questions/46940710/getting-value-from-appsettings-json-in-net-core https://stackoverflow.com/questions/46940710/getting-value-f... 280k views! And look at the sheer length of that answer. If you think they succeeded in making a good configuration library, we have very different definitions of success.

ByteJockey 6y ago

How is it that the big enterprise languages haven't gotten the ability to just mock imports yet? There are certain benefits to DI, but this one seems more like a lack of tooling.