3 ms·
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 y
by 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 agoI 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.