Inversion of Control(IOC) / Dependency Injection(DI) pattern

Today there is a greater focus than ever on reusing existing components and wiring together disparate components to form a cohesive architecture. But this wiring can quickly become a daunting task because as application size and complexity increase, so do dependencies. One way to mitigate the proliferation of dependencies is by using Dependency Injection (DI), which allows you to inject objects into a class, rather than relying on the class to create the object itself.

Inversion of Control(IoC) is a key part of what makes a framework different to a library. IoC follows Hollywood Principle("Don't call us, we'll call you").A library is essentially a set of functions that you can call, these days usually organized into classes. Each call does some work and returns control to the client.A framework embodies some abstract design, with more behavior built in. In order to use it you need to insert your behavior into various places in the framework either by subclassing or by plugging in your own classes. The framework's code then calls your code at these points.

Dependency Injection in a Software Context

Software components (Clients), are often a part of a set of collaborating components which depend upon other components (Services) to successfully complete their intended purpose. In many scenarios, they need to know “which” components to communicate with, “where” to locate them, and “how” to communicate with them. When the way such services can be accessed is changed, such changes can potentially require the source of lot of clients to be changed.

One way of structuring the code is to let the clients embed the logic of locating and/or instantiating the services as a part of their usual logic. Another way to structure the code is to have the clients declare their dependency on services, and have some "external" piece of code assume the responsibility of locating and/or instantiating the services and simply supplying the relevant service references to the clients when needed. In the latter method, client code typically is not required to be changed when the way to locate an external dependency changes. This type of implementation is considered to be an implementation of Dependency Injection and the "external" piece of code referred to earlier is likely to be either hand coded or implemented using one of a variety of DI frameworks.

Usage of Dependency Injection requires that the software we write to declare the dependencies, and lets the framework or the container work out the complexities of service instantiation, initialization, sequencing and supplies the service references to the clients as required.


Dependency Injection Demystified -

A beginner's guide to Dependency Injection by Dhananjay Nene -

Inversion of Control Containers and the Dependency Injection pattern (Martin Flower) -

Dependency Injection by Griffin Caprio(with .Net sample code) -

Inversion of Control and Dependency Injection: Working with Windsor Container -

Design Better Software with the Inversion of Control Pattern -

Is IOC and Dependency Injection the Same Thing? by Dr.Chuck -

Inversion of control and Dependency injection -

Inversion of Control and Dependency Injection -

Inversion of Control(IoC) from Microsoft Blog -

Microsoft(msdn) Architecture Journal -

Enterprise Architecture, Patterns and Practices(msdn) -

Design pattern – Inversion of control and Dependency injection By Shivprasad koirala -