For exploring MVC more, today I will share one of the interesting facts about Dependency Injection via constructor. There are many other ways to do the DI however I thought to explain how to implement this. Probably I’ll cover others in my future articles. Kindly visit the latest article that I wrote at the very start of this month.
Similarities and Dissimilarities Between MVC and Web Forms
I have seen many articles about Dependency Injection. And thought to write an article to inject dependency after initializing the DBContext object.
Object-oriented applications have a major component of design, "loose coupling".
Loose coupling means that objects should only have as many dependencies as is needed to do their job and the dependencies should be fewer. In addition to this, an object's dependencies should be on interfaces and not on "concrete" objects, a concrete object is any object created with the keyword "new".
The technique "Inversion of Control" (IOC) can be used for loose coupling. Kindly have a look at the following link to understand IOC.
S.O.L.I.D Principle Inversion of Control and Resolution With Dependency Injection
There are two primary approaches to implement DI: constructor injection and setter injection. I’ll be focusing on constructor injection.
Now the question is “if we don’t create an object using new then how would it call the required action to perform some operation (method)”. The answer is of course it would create an object using new but not in the same class and inject into another object (in other words constructor level) so that it could minimize the dependency within any class.
An Excerpt from MSDN
Dependency Injection (DI) means that this is done without the object intervention, usually by a framework component that passes constructor parameters and set properties.
The Dependency Injection (DI) Design Pattern
At a high level, the goal of Dependency Injection is for a client class (for example a golfer) needs something that satisfies an interface (for example IClub). It doesn't care what the concrete type is (for example WoodClub, IronClub, WedgeClub orPutterClub), it wants someone else to handle that (for example a good caddy). The Dependency Resolver in ASP.NET MVC can allow you to register your dependency logic somewhere else (for example a container or a bag of clubs).

Dependency Injection Golf analogy
I’ll be using Unity 2.x to maintain the IOC in my solution. Kindly download the Unity 3 - April 2013
UnityQuickStarts.zip that is being used in this solution, though I’ll explain each step so that it can be understood better by everyone. I am always trying to keep my article more readable and understandable.
So let’s start with the implementation now. I’ve created a sample application in MVC3 having the structure given below along with the Unity DLLs marked with red.

Note
There is a folder named Services having an interface IEmployee and a class Employee that implements an IEmployee interface. We’ll inject the IEmployee interface object into our controller via constructor rather than creating an object of DBContext in the same class. Now the Employee class is responsible for creating an object of DBContext using the new keyword.
I’ve added the required reference to the Unity DLL. Kindly look at the depicted image below:

There is a class named UnityDepandencyResolver to resolve the dependency also depicted in the following image.
Key Note
In MVC 4 whenever you will install Unity using the NuGet Manager it will auto-install in your solution with the name "BootStrapper.cs".

We’re almost done but now certainly the question “how we’d inject the dependency in a respective controller” is relevant because it’s not magic.
The solution is: register your controller, interface and class in Global.asax and here is the code segment for that.
Join the conversation! Your thoughts help the community grow.
Sign in to leave a comment
It is the same account you read, post and publish with — and you will come straight back to this page.





Sachin KaliaPosted Jan 15, 2014, 2:11 AM
Thanks Bro :)
Vithal WadjePosted Jan 14, 2014, 1:11 PM
good explanation,keep it up