Now that we've discussed dependency injection basics and how dependencies are contained (connected together),
I'd like to walk you through some final DI concepts and highlight the DI acid test: can your units of work be tested in isolation. Lastly, I've included some
links to open source, IoC containers, that are available for your dependency injection pleasure as well as to link to open source mocking frameworks.
In my first post on DI, I discussed Dependency Injection basics and made the point that, if you aren't practicing DI in your day-to-day design activities, YOU SHOULD BE. In this article I will speak about the glue that is needed in order to make DI a functional and extensible part of your software design.
For years now Dependency Injection (DI) has been at the forefront of discussion within the software architecture and development communities. Even though the concept of DI is not earth-shattering in its basic form, the act of NOT practicing DI has yielded mountains of legacy systems and code that become increasingly difficult to support over time. In this 3-part series, I’d like to tackle an explanation the design principles that govern DI and prove that becoming a DI practitioner is a requirement for you to succeed in your software design and coding endeavors.