So I’ve got an engagement to speak about Ajax with Visual Studio 2010. Of course, I’m talking about jQuery but there is obviously the Ajax Control Toolkit available for the people who are still on ASP.NET WebForm.

With such a huge focus right now on ASP.NET MVC, is the Ajax Control Toolkit still relevant?

The website is still there, the link toward the forums doesn’t work anymore and of course there is this gem :

AJAX Control Toolkit Release Notes - September 2009 Release Version 3.0.30930

We are 1 year and a half since the last major release. Of course, the CodePlex project is still there but the reviews are not encouraging me to use it.

Hell, the project could not even be mentioned as actively maintained anymore. One commit a month is hardly what I call support for such a project.

So the question remains… is it still relevant today? Will it ever be updated in the future?

Tools used

• Ninject 2.2.0.0
• Unity 2.0
• Visual Studio 2010

Initial premise

The way to do Dependency Injection in ASP.NET MVC 3 is basically simple compared to previous versions. ASP.NET MVC 3 expose a static class called DependencyResolver. This class has one static method called SetResolver that takes into parameter an IDependencyResolver. This allows you to set a custom resolver that ASP.NET MVC 3 will you to instantiate your controllers with. Really easy stuff. As you can see, this is a really simple interface to implement.

Ninject

Ninject (an open-source tool) already comes with one since December 6th 2010. This allows you to simply set any configured Ninject StandardKernel as a parameter to the resolver and give it to the DependencyResolver.

Unity

Unity, however, doesn’t call it a DependencyResolver. The class we are looking for is UnityServiceLocator. Although it doesn’t seem quite apparent, it’s actually compatible with the DependencyResolver implementation and can be used with it.

Bindings

Ninject

Bindings with Ninject (without extensions) are done like this:

var kernel = new StandardKernel();
kernel.Bind<IHelloWorld>().To<HelloWorld>();

Unity

Bindings with Unity (without extensions) are done like this:

var container = new UnityContainer();
container.RegisterType<IHelloWorld, HelloWorld>();

This shows off how easy it is for both to setup.

Extensions

Ninject

There is a lot of extensions available on top of the actual Ninject project. Ninject is basically only caring about the basic bindings and let the extensions to handle the rest. There is extensions for everything. From injection, conventions, message broker, etc. Here is a few that are, for me, the most interesting:

• Ninject.Web.Mvc
• Ninject.Extensions.Conventions
• Ninject.Extensions.Interception

Unity

There doesn’t seem to be any extensions available through Unity but rather be already included within the library itself. This might not be the best tactic as the releases of Unity are quite far away from each other and waiting for an update might take weeks or even months. Unity seems to be able to handle UnityContainerExtension but there is not much on the web that was developed by the open source community.

Which one to choose?

At that point, there isn’t much that differentiate both. It’s mainly a matter of taste whether you like on syntax or the other. However, on the extension side… there is a definite edge on the Ninject project.

Ninject project is definitely more active and you can see each and every modifications made in the source control on GitHub.

So in my previous post, we talked about binding interface/abstract class to implementations with Ninject. It was a rather simple task and it allowed us to do the job quite easily.

But of course the example was a simple case and would never ever even look close to a real production project. A real production project might have 3-4 services with at least 2-3 dependencies each that might or might not be the same. This can easily explode when adding new functionalities to a software. Need to send email? Add a dependency on INotifier. Need to access another service elsewhere? Another dependency. This can grow quite big quite fast and it will be a pain to actually maintain all the bindings.

This is where “Ninject.Extensions.Conventions” (NEC) come and save us some time.

Let’s take the following code and binding from our previous example:

using System;
using Ninject;

namespace ConsoleNinject
{
    class Program
    {
        static void Main(string[] args)
        {
            var kernel = new StandardKernel();

            kernel.Bind<IConsoleOutput>().To<MyConsoleOutput>();

            var output = kernel.Get<IConsoleOutput>();
            output.HelloWorld();

            var service = kernel.Get<Service>();
            service.OutputToConsole();

            Console.ReadLine();
        }
    }


    public interface IConsoleOutput
    {
        void HelloWorld();
    }

    public class MyConsoleOutput : IConsoleOutput
    {
        public void HelloWorld()
        {
            Console.WriteLine("Hello world!");
        }
    }

    public class Service
    {
        private readonly IConsoleOutput _output;

        public Service(IConsoleOutput output)
        {
            _output = output;
        }

        public void OutputToConsole()
        {
            _output.HelloWorld();
        }
    }
}

So we only have one line of binding. Now don’t forget that this line will explode to 4, 6, 10, 20 lines as things move forward. We want to simplify this to the most simplest case.

This line can be replaced with the following:

kernel.Scan( x=>
    {
        x.FromAssembliesMatching("*");
        x.BindWith<DefaultBindingGenerator>();
    });

However, running the code after that won’t work. Why? Because the DefaultBindingGenerator binds I{Name} to {Name}. Quite simple but it’s extendable.

So we need to change the name of our class MyConsoleOutput to ConsoleOutput and then everything works!

There you go! Now we can keep on adding interfaces and implementations without changing the actual binding codes.

On another note, you might want to change which assemblies are loaded for the conventions since this would load all DLLs in the executing directory.

Links

• Official Ninject website
• Ninject on Github
• Ninject download list

What is Ninject?

Ninject is a Inversion of Control (a.k.a IoC) tool that allows you to map Interfaces to Implementations.

An IoC main job is to instantiate an object that is linked to a requested type. An IoC tool will also control the lifetime of those objects to allow more flexibility in the invocation of them.

How do I use it?

Well first, you have to download the original version from the Ninject Github site.

There, you are met with many different options that will allow you to match your need. It is important to notice that if you are using a specific Ninject Extension, it requires the same version of Ninject to be used (packaged inside the Extension’s zip file).

For the demo purpose, we’re going to use the .NET 4.0 version of Ninject.

Prerequisites

Now let’s try to build a simple project. We’ll create a solution containing only a Console application for demo purpose and add the Ninject reference.

Then we need an interface and a class implementing that interface to simulate a real-life situation.

public interface IConsoleOutput
{
    void HelloWorld();
}

public class MyConsoleOutput : IConsoleOutput
{
    public void HelloWorld()
    {
        Console.WriteLine("Hello world!");
    }
}

Once this is implemented, we have everything we need to implement a simple demo for Ninject.

Ninject Implementation

So in a highly coupled application, we would see a direct invocation of MyConsoleOutput and it would end there. However, when that class change or if we want to test that class, it will be impossible to do so without invoking it. By coding directly against an interface or an abstract class, it allows us to decouple the implementation and the contract.

So next, we need to implement the standard ninject container that will hold “Bindings”. Those bindings represent the link between an interface and it’s implementation. Under Ninject, the container is called a Kernel and is represented by the class StandardKernel.

var kernel = new StandardKernel();

Then we create the binding between IConsoleOutput and MyConsoleOutput.

kernel.Bind<IConsoleOutput>().To<MyConsoleOutput>();

Finally, we’ll request an instance of IConsoleOutput and execute it. You should receive a “Hello world” on your console.

var output = kernel.Get<IConsoleOutput>();
output.HelloWorld();

Well that was easy! But what if it’s a dependency on another object? Like this:

public class Service
{
    private readonly IConsoleOutput _output;

    public Service(IConsoleOutput output)
    {
        _output = output;
    }

    public void OutputToConsole()
    {
        _output.HelloWorld();
    }
}

Requesting the Service like this and executing it will lead to the same result.

var service = kernel.Get<Service>();
service.OutputToConsole();

That’s it!

Conclusion

So Ninject resolves the dependencies of specific objects. What isn’t shown in this demo is that dependencies on dependencies are also going to be resolved. This allows you to build object graph really easily without having to build a factory or have a huge instantiations call. This allows you to have objects that are loosely coupled and highly testable.

Of course, Ninject isn’t the only tool that can do that job but so far, I’ve found it to be the easiest.

The alternatives

• Unity by Microsoft
• StructureMap
• AutoFac
• Castle Windsor

Ninject is my favorite container for doing dependency injection. However, it always seemed a bit complicated to use with ASP.NET WebForms.

Things have improved with ASP.NET MVC 1 of course but now, with the release of ASP.NET MVC 3, things have become way easier to do.

Here is what my Global.asax.cs looks like when I want to register an IoC tool for ASP.NET MVC 3:

protected void Application_Start()
{
    AreaRegistration.RegisterAllAreas();

    RegisterGlobalFilters(GlobalFilters.Filters);
    RegisterRoutes(RouteTable.Routes);
    RegisterDependencyResolver();
}

private void RegisterDependencyResolver()
{
    var kernel = new StandardKernel();

    DependencyResolver.SetResolver(new NinjectDependencyResolver(kernel));
}

Well that look easy enough no? Well, to be fair… NinjectDependencyResolver doesn’t exist. It’s a custom class that I created to allow the easy mapping of the Kernel.

The only thing it needs is the Ninject StandardKernel. Once all the mappings are done, we give the kernel to the resolver and let MVC handle the rest.

Here is the code for NinjectDependencyResolver for all of you to use:

public class NinjectDependencyResolver : IDependencyResolver
{
    private readonly IKernel _kernel;

    public NinjectDependencyResolver(IKernel kernel)
    {
        _kernel = kernel;
    }

    public object GetService(Type serviceType)
    {
        return _kernel.TryGet(serviceType);
    }

    public IEnumerable<object> GetServices(Type serviceType)
    {
        try
        {
            return _kernel.GetAll(serviceType);
        }
        catch (Exception)
        {
            return new List<object>();
        }
    }
}

Well hello everyone,

So I updated from Blogger to .NET Blog Engine 2.0. The transfer was painful indeed. Blogger isn’t supporting a pure BlogML markup and I had to convert everything to the new format. Including of course fixing all the slugs and the old url so that they could still works.

Since this new engine will allow me more flexibility, the frequency of posts shall increase.

See you all later!