I wrote my first blog post about achieving dependency injection using Ninject right here, there we have discussed about some basic stuff and even tried a small sample. One of the nice things about Ninject is there are different extensions available along with the core assemblies to work with different frameworks. Ninject has extension to work with ASP.NET MVC framework as well. Along with the core assemblies we need to add assemblies Ninject.Web.Common and Ninject.Web.Mvc to use in MVC projects. Ninject.Web.Common is a common library for both web-forms and MVC. You can download the Ninject core and extensions from here.

We have two options to use Ninject MVC extensions in projects: one is adding the binaries directly to the projects and the other way is installing from NuGet Package Manager Console (Install-Package Ninject.MVC3). In this post we have used the first approach.

"Ninject is a lightweight dependency injection framework for .NET applications. It helps you split your application into a collection of loosely-coupled, highly-cohesive pieces, and then glue them back together in a flexible manner. By using Ninject to support your software's architecture, your code will become easier to write, reuse, test, and modify."

In this tutorial we are going to have a first look at using Ninject in .NET for dependency injection.

Dependency Injection (DI) is a design pattern in Object Oriented Programming where the dependencies of a class are injected at runtime. These dependencies are mostly injected through a constructor (Constructor DI) or a property (Property DI). One of the main advantages of DI is it simplifies unit testing by allowing to inject mock dependencies in the place of real classes. In some cases we should have a default constructor in classes like in ASP.NET MVC controllers, WCF services etc. In WCF the service classes should have a default constructor else the framework will throw a runtime exception. To solve this problem developer ends up writing two constructors one is default and the other one is parameterized. The default constructor is used by the framework and the parameterized one is used by developers at the time of unit testing.

Although having two constructors suffice the job but we are violating the principles of dependency injection by instantiating the concrete classes in the default constructor. WCF is a highly extensible framework and fortunately it provides extension points even to customize the service instantiation. It looks like some of the DI containers simplify our job of customizing service instantiation by providing their own custom service host factories.

In this article we are going to see about the WCF extension point IInstanceProvider that allows us to customize the service instantiation and how the DI container Castle Windsor simplifies the task of creating services without default constructor through its new integration facilities.