I'm planning to do a talk on Dependency Injection and IoC Containers, and I'm looking for some good arguments for using it.
What are the most important benefits of using this technique, and these tools?
Most important, for me, is making it easy to follow the Single Responsibility Principle.
DI/IoC makes it simple for me to manage dependencies between objects. In turn, that makes it easier for me to break coherent functionality off into it's own contract (interface). As a result, my code has been far more modularized since I learned of DI/IoC.
Another result of this is that I can much more easily see my way through to a design that supports the Open-Closed Principle. This is one of the most confidence inspiring techniques (second only to automated testing). I doubt I could espouse the virtues of Open-Closed Principle enough.
DI/IoC is one of the few things in my programming career that has been a "game changer." There is a huge gap in quality between code I wrote before & after learning DI/IoC. Let me emphasize that some more. HUGE improvement in code quality.
The examples that really opened my eyes were seeing how it made it possible to easily unit test the objects created in such a fashion. Prior to that, I had trouble attempting to isolate objects for a unit test. I would often write tests to interacted with a much larger system. This was really hard because the system as a whole was much less predictable and much more prone to change then the individual components.
I think the actual benefits are more political than technical. DI is simply an alternative to the Service Locator pattern, nothing more. By itself, it does not make it easier to follow principles like SRP or OCP, or to decouple layers. Other respondents here are confusing different concepts and techniques, IMO.
You can achieve the same goals with respect to high cohesion and low coupling by using Service Locators, or by simply instantiating dependencies directly whenever applicable (which is most of the time).
Now, I know many will disagree with this opinion. I will be glad to discuss concrete examples.
The first and foremost thing is that it allows the decoupling of view and the logic of your application. Your view needn't know how the business logic, data etc are handled. This allows you to do quick UI changes, according to user experience feedback. Also if something on the back-end is changed the UI doesn't even have to modified a little.
MVC architecture uses this design pattern to separate the parts. It also allows for multiple persons to work together effectively in case of big enterprise applications.
Thank you for your interest in this question.
Because it has attracted low-quality or spam answers that had to be removed, posting an answer now requires 10 reputation on this site (the association bonus does not count).
Would you like to answer one of these unanswered questions instead?