4 ms·

This has become so seeped into how we develop dotnet c# past couple of years. Just using Microsoft built in ServiceCollection. Honestly I think this is the mos

by peheje 3y ago

This has become so seeped into how we develop dotnet c# past couple of years. Just using Microsoft built in ServiceCollection. Honestly I think this is the most important pattern in my line of work. It has become so common for me. That when I see c# code not using it. It almost looks like another language. Testing becomes so easy because everything is easy to mock out. Be it in a unit test using some mock framework. Or a real 'integration-test' where you write a small in memory queue mock by hand to easy your tests. Object lifetime is easy to change and manage. Just how you register the dependency. As scoped (to http request for example) as transient (every time you ask) or singleton? Want to do something before/after with some hook? Just Decorate the dependency and register it to the container. Nothing feels tangled. Just inject the service. Call the method. Do the thing. No need to worry about cleanup or how to create the dependency. It's already setup.

tester756 3y ago
>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
- nh23423fefe 3y ago
  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.
  - tester756 3y ago
    >I don't see what IO has to do with it. 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? >DI I'm talking about containers, just containers. DI != DI containers
    - nh23423fefe 3y ago
      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.

by peheje 3y ago

tester756 3y ago

>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

nh23423fefe 3y ago
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.
- tester756 3y ago
  >I don't see what IO has to do with it. 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? >DI I'm talking about containers, just containers. DI != DI containers
  - nh23423fefe 3y ago
    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.