I can't speak from experience, as I never built such a framework, but I would say the complexity comes from building (potentially complex) objects graphs automatically at runtime, given the configuration we provide.
In C# (and for what I've seen of Java) the solutions are very similar to this. Other languages have probably different approaches, maybe they're simpler, can't really say.
I had ever done java and c# projects and know a little DI like spring. Later I select Ruby, when I do rails project I find I need DI to mock test, but no need for DI framework.
Maybe big project need a complicated DI framework like Spring.
Ah, I see, you create a factory and then use it instead of creating the Product directly.
In C# we normally use the dependency injection container as the factory (we still use factories on occasion, but for different reasons).
Using the container as the factory, and it being tightly integrated into the web framework, in the controllers, like you can see above, we just add the dependencies we want in the constructor, and the framework passes them in automatically.
Yupe. Different ways to get to the same end result of decoupling components 🙂
I like the C# approach, probably because I'm used to it, but I can understand that coming from other languages it seems overly complex.
Being able to just declare the dependencies in the constructor and they'll be there when running is nice (even if a bit magic) and gives quick visibility on the dependencies of a given class just by looking at the constructor. It does come with the hidden complexity you talked about, so as always, there are trade offs.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
DI is just a parameter of method, why so complicated?
You're right, DI is really a simple concept.
I can't speak from experience, as I never built such a framework, but I would say the complexity comes from building (potentially complex) objects graphs automatically at runtime, given the configuration we provide.
In C# (and for what I've seen of Java) the solutions are very similar to this. Other languages have probably different approaches, maybe they're simpler, can't really say.
I had ever done java and c# projects and know a little DI like spring. Later I select Ruby, when I do rails project I find I need DI to mock test, but no need for DI framework.
Maybe big project need a complicated DI framework like Spring.
Yeah, didn't do anything with Ruby myself, so can't make a good comparison.
Maybe we're lucky and there's another DEV member reading this that has experience in both and wants to chime in 🙂.
Welcome, happy to talk DI with you. I have the short ruby code to demo:
Ah, I see, you create a factory and then use it instead of creating the
Product
directly.In C# we normally use the dependency injection container as the factory (we still use factories on occasion, but for different reasons).
Using the container as the factory, and it being tightly integrated into the web framework, in the controllers, like you can see above, we just add the dependencies we want in the constructor, and the framework passes them in automatically.
In Ruby code is like this. Don't need a DI container.
Yupe. Different ways to get to the same end result of decoupling components 🙂
I like the C# approach, probably because I'm used to it, but I can understand that coming from other languages it seems overly complex.
Being able to just declare the dependencies in the constructor and they'll be there when running is nice (even if a bit magic) and gives quick visibility on the dependencies of a given class just by looking at the constructor. It does come with the hidden complexity you talked about, so as always, there are trade offs.