That's because many people who explain it are clueless as well and tell you some overcomplicated bullshit. Actually it's quite a simple thing, not much more than programming against interfaces instead of implementations. You should know about it because it simplifies unit testing. Once you got this, you will find other benefits.
I like how IoC takes away the responsibility of layers to know about the creation of other layers (or their scope). Via DI, my controller can have a repository object injected by the IoC container, and the controller doesn't have to manage the lifecycle of the repository object.
Also, in unit tests, the repository object is easier to mock because I don't have my controller creating the instance in a constructor or something my test doesn't have access to.
DI can make things harder to read if the framework is limited to injecting interfaces and the interfaces have several implementations.
If you understand the difference between composition and inheritance in OOP you understand dependency injection, the rest is lingo to make it sound more complicated than it actually is
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.
I have no idea what dependency injection is and why I need to know about it.
That's because many people who explain it are clueless as well and tell you some overcomplicated bullshit. Actually it's quite a simple thing, not much more than programming against interfaces instead of implementations. You should know about it because it simplifies unit testing. Once you got this, you will find other benefits.
I like how IoC takes away the responsibility of layers to know about the creation of other layers (or their scope). Via DI, my controller can have a repository object injected by the IoC container, and the controller doesn't have to manage the lifecycle of the repository object.
Also, in unit tests, the repository object is easier to mock because I don't have my controller creating the instance in a constructor or something my test doesn't have access to.
DI can make things harder to read if the framework is limited to injecting interfaces and the interfaces have several implementations.
If you understand the difference between composition and inheritance in OOP you understand dependency injection, the rest is lingo to make it sound more complicated than it actually is