5 ms·

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).

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).