Dependency Injection
To understand DI better, lets develop a hypothetical role based application where the rendered view for the user depends upon the ROLE the user possesses. In a typical ASP.Net Application(c’mon I have been asp.net developer for 6+ years…will take some time ),membership services will do the trick or if the developer is enthusiast enough, he/she will write some custom classes.
In either of the scenarios, the Code Behind file will render view depending upon the role. Let’s say there are 4 views (AdminView, DeveloperView, Manager View, SupervisorView).
If I develop a pseudocode for administering admin user view, it wil be something like the following
If (userRole==Admin)RenderView= AdminView
To get into some details, it’s the code-behind(or rather say controller) that decides which view to render. How about the Views being intelligent enough, to know which controller (class/objects) to call and give the required results. This is where comes the Dependency Injection….injecting the dependencies into the view.
What exactly is Dependency Injection?
According to WikiPedia, Dependency injection (DI) is nothing but a design pattern in object-oriented programming whose primary purpose is to improve testability and simplify deployment of components in enterprise software development environment.
The Dependency Injection pattern involves at least three elements:
- A dependent consumer,
- A declaration of a component's dependencies,, defined as interface contracts,
- An injector (sometimes referred to as a provider or container) that creates instances of classes that implement a given dependency interfaces on request.
The dependent object describes what components it depends on to do its work.
The injector decides what concrete classes satisfy the requirements of the dependent object, and provides them to the dependent.
Note:
In conventional software development the dependent object decides for itself what concrete classes it will use; in the dependency injection pattern, this decision is delegated to the "injector" which can choose to substitute different concrete class implementations of a dependency contract interface at run time rather than at compile time.
If you feel like Class inheritance would have solved the purpose, please clarify the doubts by reading this Dependency Injection(DI )vs Class Inheriance article.
Types of Dependency Injection
There are three common forms of dependency injection:
- Constructor Injection(uses parameters to inject dependencies in constructor)
- Setter Injection (setter methods,are used to inject the object's dependencies)
- Interface-based injection (an interface is used to inject dependencies)
The example puts a small demonstration of how these types are implemented.
This link can help you understand DI better from SilverLight perspective.
Are Dependency Injection(DI) and Inversion of Control (IOC) inter-related
The relation between these two patterns can be understood from these lines article
“Inversion of Control and Dependency Injection are two related ways to break apart dependencies in your applications.
Inversion of Control (IoC) means that objects do not create other objects on which they rely to do their work. Instead, they get the objects that they need from an outside source (for example, an xml configuration file).
Dependency Injection (DI) means that this is done without the object intervention, usually by a framework component that passes constructor parameters and set properties.”
If you still need some more clearance, refer to this article.
Dependency injection/IOC Frameworks(containers)
To implement IOC, the developers have been thrown up with lots of IOC frameworks that have been listed here.
Which one to use is entirely your call or may be your project’s requirements or simply your boss’s wish.
A very interesting way to decide would be to user the poll results mentioned here
Hope this was useful.
Till next we connect…
Happy reading….
Comments
Post a Comment