The terms Dependency Injection and Inversion of Control are colloquially used interchangeably and numerous times, the distinction is lost. In one of the DI must read books, Dependency Injection in .NET by Mark Seeman, the particularity of these entities are explained quite well. Following is the excerpt.
The term Inversion of Control (IoC) originally meant any sort of programming style where an overall framework or runtime controlled the program flow.
According to that definition, most software developed on the .NET Framework uses IoC. When you write an ASP.NET application, you hook into the ASP.NET page life cycle,but you aren't in control—ASP.NET is. When you write a WCF service, you implement interfaces decorated with attributes. You may be writing the service code, but ultimately, you aren't in control—WCF is. These days, we’re so used to working with frameworks that we don’t consider this to be special, but it’s a different model from being in full control of your code. This can still happen for a .NET application—most notably for command-line executables. As soon as Main is invoked, your code is in full control. It controls program flow, life-time, everything. No special events are being raised and no overridden members are being invoked.
Before DI had a name, people started to refer to frameworks that manage Dependencies as Inversion of Control Containers, and soon, the meaning of IoC gradually drifted towards that particular meaning: Inversion of Control over DEPENDENCIES. Always the taxonomist, Martin Fowler introduced the term Dependency Injection to specifically refer to IoC in the context of dependency management. Dependency Injection has since been widely accepted as the most correct terminology.
In short, IoC is a much broader term that includes, but isn’t limited to, DI.
References:
Pluralsight - Inversion of Control Course with StructureMap, Unity, Castle Windsor and Ninject
