>That when I see c# code not using it. It almost looks like another language.
On the other hand
While I see the value of DI containers in web apps (ASP.NET)
Then I don't really see the value of it in console apps (tools) (yea, asp app is console too, ik.)
You may ask what's the difference and in my opinion the difference is: input/output flow model
In web app you run your app with some args/envs, and then you're receiving request and return them results.
In console app your run your app with some args/envs and then you're doing stuff until you complete (ofc unless you're listening/waiting for things... like in web app)
In this 2nd model DI containers seem to not give me anything useful. You even were writing about this here:
>"Just how you register the dependency. As scoped (to http request for example) as transient (every time you ask) or singleton?"
It fits asp request/response model very well, but for other things? I dont feel it
The value was always the implicit object graph. I don't see what IO has to do with it. DI lets you label nodes and the container toposorts and makes edges for you.
ASP web framework creates instances of Controllers (handlers) on request basis, that's when they need to resolve dependencies in order to create them, so it fits it very well.
But when I need to create instance of some repository, some background job handler and some csv writer, then why would I want to do it via DI container?
I guess I would call that scoping. Dagger can do this at resolution at compile time for example. So I don't see the connection to runtime resolution.
> why would I want to do it via DI container
I guess I don't follow why you wouldn't. Like, already assuming we are competent people, then you extend your object graph when it makes sense.
Does a prototype bean for {new ArrayList()} make sense? Probably not. But I could definitely see wiring up a CSVWriter with config properties from a container populated from various resources.
I buy the simple argument that DI is a better "new" and containers are just the interface to an named object graph.
On the other hand
While I see the value of DI containers in web apps (ASP.NET)
Then I don't really see the value of it in console apps (tools) (yea, asp app is console too, ik.)
You may ask what's the difference and in my opinion the difference is: input/output flow model
In web app you run your app with some args/envs, and then you're receiving request and return them results.
In console app your run your app with some args/envs and then you're doing stuff until you complete (ofc unless you're listening/waiting for things... like in web app)
In this 2nd model DI containers seem to not give me anything useful. You even were writing about this here:
>"Just how you register the dependency. As scoped (to http request for example) as transient (every time you ask) or singleton?"
It fits asp request/response model very well, but for other things? I dont feel it