Dependency Injection Inversion Of Control And Unity


Published on

A brief overview on the Dependency Injection concept and its implementation

  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Dependency Injection Inversion Of Control And Unity

  1. 1. Inversion Of Control (IOC) and Unity Framework<br />Presented by : M.M.Al-FarooqueShubho<br /><br />
  2. 2. Dependency Injection in real world<br />Story 1:<br />All employees in Jaxara has to pay yearly income tax and each employee knows the tax lawyer to communicate to (Via phone) for handling tax matters. <br />Story 2:<br />All employees in Jaxara has to pay yearly income tax and the HR manager handles the tax issue of each employee by communicating with a lawyer. For tax related matters, the HR manager communicates with Employees about who the tax lawyer. When an employee needs to communicate with the tax lawyer, he/she does that via the HR Manager (Because, he knows how to communicate with the lawyer).<br />
  3. 3. What if there is a change?<br />What if For any reason <br />The tax lawyer is changed, <br />or, <br />The tax lawyer changes his/her communication mechanism <br />
  4. 4. What is the change impact?<br />Story 1<br />Each employee needs to update themselves with the new layer info and also needs to change their communication mechanism to the lawyer (Instead of phone, communicate via a web site).<br />Story 2<br />The HR manager will update the lawyer info and notify each employee with defining the updated communication mechanism. So, when each employee will need to communicate with the lawyer, they don’t need to change their communication mechanism. <br />
  5. 5. The Problem : Tight coupling of dependent objects<br />The following class depicts the Story 1<br />public class Employee<br />{<br /> private TaxLawyer_taxLawyer;<br /> public Employee()<br /> {<br /> _ taxLawyer= new TaxLawyer ();<br /> }<br />}<br />The Employee class controls the creation of TaxLawyer objects and the TaxLawyer class is directly referred within the Employee. So, if the TaxLawyer class is replaced sometimes with another class (Say, IncomeTaxLawyer class), the Employee class needs a change.<br />
  6. 6. The Solution: Inject the depencency<br />The following class depicts the Story 2<br />public class Employee<br />{<br /> private ITaxLawyer_taxLawyer;<br /> public Employee(ITaxLawyer_taxLawyer)<br /> {<br /> this. _ taxLawyer= _ taxLawyer;<br /> }<br />}<br />The Employee class controls the creation of ITaxLawyer object, rather, an external class will instantiate the ITaxLawyer object and set it within the Employee object. <br />Note that, the ITaxLawyer is an interface, rather than a concrete class. So, if for any reason, the TaxLawyer is changed (Say, IncomeTaxLawyer) , there will be no change in the Employee class (Because, both TaxLawyer and the IncomeTaxLawyer implements ITaxLawyer) . <br />Even if the changed class (IncomeTaxLawyer) has a different communication method implementation, Employee class need not to worry about any change. It knows only about the Interface, not any concrete implementation class.<br />
  7. 7. The Dependency Injection defined<br />As we have seen already, if the object creation control is not implemented within the class, rather, if this control is assigned to an external class or entity, we get:<br />Flexibility.<br />Least change impact.<br />Cleaner code.<br />So, the principle of Dependency Injection can be defined as follows:<br />“Do not call us we will call you” (Hollywood principle)<br />Its like TaxLawyer class saying to the Employee class, do not create me, rather, I will create myself using some one else. <br />
  8. 8. Principles of DI<br />Main classes aggregating other classes should not depend on the direct implementation of the aggregated classes, rather, should depend on abstract implementation (Interface).<br />Abstraction (Interface) should not depend on detail (Class), rather, the detail should depend on the abstraction.<br />
  9. 9. The Inversion of Control (IOC)<br />As we have seen, in the Dependency Injection, there should be an external entity (Class) who should handle the object creation and inject those in the dependent object. This idea is called Inversion of Control (IOC).<br />The external class is called IOC Container. The IOC container allows to register objects within it and also handles instantiation of the object with their dependent objects (The object graph) and allows to retrieve objects from the container.<br />
  10. 10. Unity, the IOC Framework/Container <br />The Unity Application Block (Unity) is a lightweight, extensible dependency injection container that supports constructor injection, property injection, and method call injection.<br />How to use Unity?<br />Download Unity Application Block from<br />Add reference to Microsoft.Practices.Unity, Microsoft.Practices.Unity.Configuration<br />Create a Factory class that would initialize the UnityContainer and expose type/object registration and retrieval functionality within the Unity container.<br />
  11. 11. Unity, the IOC Framework/Container <br />Within the Factory class, do the followings:<br /> Create a new instance of the UnityContainer class or use a reference to an existing instance (Possibly, in the constructor)<br />IUnityContainermyContainer = new UnityContainer(); <br />Create a method to register objects within the container. Use RegisterType method of container class to register a type into the container. <br />myContainer.RegisterType<typeof(ITaxLawyer), typeof(IncomeTaxlawyer)>();<br />The lifetime of the object it builds will correspond to the life time specified in the parameters of the method. <br />If lifetime is not specified then the type will registered for a transient lifetime, which means that a new instance will be created on each call to Resolve. ( It is method , which will be discussed later) <br />
  12. 12. Unity, the IOC Framework/Container <br />Create a method that accept a Type parameter for retrieving object from the container. Within the method, use the Resolve method to retrieve object instances from the container. <br />ITaxLawyer lawyer = _container.Resolve(ITaxLawyer)<br />To get exact concrete object use:<br />IncomeTaxLawyer lawyer = _container.Resolve(IncomeTaxLawyer)<br />