Dependency injection is also known as “Inversion of Control,” as originally described by Robert Martin. Interestingly enough, the development community typically uses the phrase “dependency injection” when talking about the technique itself and “IoC” when talking about dependency injection containers. But rest assured, there is no difference whatsoever between “Dependency Injection” and “Inversion of Control (IoC).”
Dependency Injection - Enables loosely coupled/dependent apps.
You inject a class's dependencies into it, through a constructor or a series of setters, rather than instantiating them in the class. It can be done WITHOUT an IoC container.
Tightly/Highly Coupled Dependencies
HomeController is tightly coupled/dependent on the Employee class, without the Employee class its not much use...
public class HomeController : Controller
{
public ActionResult Index()
{
Employee employee = new Employee();
return View();
}
}
Still tightly coupled to the Employee class...
public class HomeController : Controller
{
private readonly Employee _emp;
public HomeController(Employee emp)
{
this._emp = emp;
}
public ActionResult Index()
{
ViewBag.Message = _emp.GetName();
return View();
}
}
Loosely Coupled Dependencies
Using an Interface allows us to pass any object that implments this Interface, this allows us to pass fake objects which makes Testing easier...
public class HomeController : Controller
{
private readonly IEmployee _emp;
public HomeController(IEmployee emp)
{
this._emp = emp;
}
public ActionResult Index()
{
ViewBag.Message = _emp.GetName();
return View();
}
}
There are three main styles of dependency injection
Constructor injection.
Passing an object's dependencies to its constructor.
examples above
Setter injection.
Dependencies are set onto public properties exposed by the object in need. Dont need to modify the constructor of a legacy class.
Allows expensive resources or services to be created as late as possible and only when needed.
Should be used sparingly in place of Constructor Injection, because it:
Does not make it clear to the developer which dependencies are needed when, at least until a "has not been initialized" exception is thrown.
Makes it a bit more difficult to track down where the exception came from and why it got thrown.
Interface injection.
seems to be very similar to Controller Injection above, good description, http://www.martinfowler.com/articles/injection.html
The third injection technique is to define and use interfaces for the injection. With this technique you define an interface that you use to perform the injection through.
This configuration has two stages, registering components through lookup keys is pretty similar to the other examples.
A new step is to register the injectors that will inject the dependent components. Each injection interface needs some code to inject the dependent object.
Injection Options (Injectors)
The next logical question is, what actually creates the dependencies that are to be injected into "injectees"? There are two appropriate places for adding creation logic: controllers and containers.
Manual Injection/DI Controllers
This requires the HomeController to be instantiated somewhere and dependencies supplied using constructor injection, which I presume is not an easy option with MVC.
Regardless of what you use as your controller, the controller is an appropriate location for performing Dependency Injection "wiring". This is where concrete objects are created and injected as dependencies.
Automatic Injection/DI Container
Inversion-of-Control/Dependency-Injection "Containers" can be used to watch an application and inject dependencies whenever a particular event occurs. For example, whenever a HomeController instance is created, it automatically gets injected with its needed dependencies.
Dependency injection involves at least three elements:
1) a dependent consumer - HomeController
2) a declaration of a component's dependencies, defined as interface contracts - Constructor
3) an injector (sometimes referred to as a provider or container) that creates instances of classes that implement a given dependency interface on request - IoC container/manually.
Inversion of Control (also known as the Hollywood Principle - "Don't call us, we'll call you").
Inversion of Control is a key part of what makes a framework different to a library. 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.
One simple example of IoC is JUnit, the framework code calls setUp and tearDown methods for you to create and clean up your text fixture. It does the calling, your code reacts/implements the creation and clean up - so again control is inverted.
Inversion of Control Containers
For this new breed of IoC containers the inversion is about how they lookup a plugin(IEmployee) implementation. The approach that these containers use is to ensure that any user of a plugin follows some convention(an interface) that allows a separate assembler module to inject the implementation into the lister(HomeController).
As a result I think we need a more specific name for this pattern. Inversion of Control is too generic a term, and thus people find it confusing. As a result with a lot of discussion with various IoC advocates we settled on the name Dependency Injection.
There is some confusion these days over the meaning of inversion of control due to the rise of IoC containers; some people confuse the general principle here with the specific styles of inversion of control (such as dependency injection) that these containers use.
Using a Service Locator
The key benefit of a Dependency Injector is that it removes the dependency that the HomeController class has on the concrete Employee implementation. Injection isn't the only way to break this dependency, another is to use a service locator.
The basic idea behind a service locator is to have an object that knows how to get hold of all of the services that an application might need, needs to be investigated further...
Service Locator vs Dependency Injection
The fundamental choice is between Service Locator and Dependency Injection. The first point is that both implementations provide the fundamental decoupling that's missing in the naive example - in both cases application code is independent of the concrete implementation of the service interface. The important difference between the two patterns is about how that implementation is provided to the application class. With service locator the application class asks for it explicitly by a message to the locator. With injection there is no explicit request, the service appears in the application class - hence the inversion of control.
my thanks to:
http://www.martinfowler.com/articles/injection.html
http://en.wikipedia.org/wiki/Dependency_injection
http://www.codeproject.com/Articles/13831/Dependency-Injection-for-Loose-Coupling
http://devlicious.com/blogs/billy_mccafferty/archive/2009/11/09/dependency-injection-101.aspx
