[fearface]

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]

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

[csharptwdec19]

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

[rhencke]

A better take on DI wireups in .NET: 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<B>          Delayed instantiation
    A needs to create instances of B            Func<B>          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<B>   Enumeration

[eropple]

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]

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

[mumblemumble]

> 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]

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]

You wouldn't be using the config at all if you're not using the config files. They're part of the default project.