So there is a sweet new fluent interface, but more importantly you have to specify the exact conventions to use. This makes it a lot easier to have non-standard convention, but it would be great if Ninject had the standard convention built in (IFoo binds to Foo).

For those who are into their own custom binding conventions (like Anthony), you will unfortunately find that the IBindingGenerator interface has changed. Here is the v2.2 way of implementing a custom binding:

It must be said, however, the goodness of the new fluent interface shown above means that I no longer need a custom binding generator – instead I can simply select the types I want and bind them directly in my bootstrapper. I suspect that others will find the same!

Recently I started using Ninject for Inversion Of Control (IOC) and Dependency Injection (DI) on an ASP.Net MVC3 project. Ninject is a very neat framework and is easy to use BTW and its offers some slick MVC3 integration through the Ninject.Web.Mvc project.

Being a proponent of convention-over-configuration, I also looked for some auto-registration code for Ninject and soon found the Ninject.Extensions.Conventions project. The default convention here also suits me, since it binds IFooService to FooService in transient scope. Using the Scan extension method, I could now have the following code to initialise my IOC:

So far, so good, I thought, and now to apply IOC to my WCF services, which are hosted within the MVC web project (important point!). Once again, Ninject has an answer, in the form of the Ninject.Extensions.Wcf project. This project offers a custom ServiceHostFactory that will apply IOC to your service implementation simply by adding the Factory attribute in your .svc file:

Very nice … except that it didn’t work (yet). This didn’t surprise me much at this stage because both Ninject.Web.Mvc and Ninject.Extensions.Wcf define a custom HttpApplication class and both libraries expect you to derive from this in your global.asax.cs class. I opted to keep the class for Mvc and patch in the functionality required by the class for Wcf. [As an aside, this is only possible because of the nature of open source software – hurray for open source] So here was my first attempt:

Looking good … except that it still didn’t work. Requests to the WCF service were now all met with this:

After much head-scratching, it turns out that the IOC binding done internally by the Ninject.Extensions.Wcf project is to bind ServiceHost to NinjectServiceHost and this binding does not follow the default conventions laid down by Ninject.Extensions.Convention! Obvious really, once you understand the conventions and look at the required binding. So now the fix was pretty simple:

The moral of the story? It is possible to get MVC controllers and WCF service classes controlled by the same Ninject kernel. And if you use conventions, don’t assume that all libraries can and do use them!

A while ago I was having a discussion with one of my fellow developers at EMC Consulting about SharePoint and getting dependency injection working with it. Well finally after a few weeks I have found the time to produce a quick example of just how easy it is to get dependency injection working in SharePoint using a great tool called Ninject. You can find additional information about Ninject at http://ninject.org/. So this get started! First off Ninject works by providing you with something it calls a kernel which it uses for returning an instance of a specific type. You can think about the kernel as a big brother to the factory pattern we all know and love. Because the kernel is so important the first things you need to do to get Ninject working in SharePoint is create an instance of a kernel and a simple way to do this in SharePoint is through the use of a HttpModule.

1: publicclass SharePointNinjectHttpModule: IHttpModule, IDisposable

2: {

3: privatereadonly HttpApplication _httpApplication;

4:

5: publicvoid Init(HttpApplication context)

6: {

7: if (context == null)

8: thrownew ArgumentException("context");

9:

10: if(FrameworkHelper.Kernel == null)

11: {

12: FrameworkHelper.Kernel = GetKernel();

13: }

14: }

15:

16: publicvoid Dispose()

17: {

18: if(_httpApplication == null) return;

19: _httpApplication.Dispose();

20: }

21:

22: #region Private methods

23:

24: /// <summary>

25: /// Gets the kernel.

26: /// </summary>

27: /// <returns></returns>

28: privatestatic IKernel GetKernel()

29: {

30: IKernel result = new StandardKernel();

31: result.Bind<IWarrior>().To<Samurai>();

32: result.Bind<IWeapon>().To<Sword>();

33: return result;

34: }

35:

36: #endregion

37: }

As you can see from the code the module is very simple and straightforward and all it does is create an instance of the kernel and sets it's bindings so Ninject knows which instance of a type to return when a request for “IWarrior” or “IWeapon” is made. Remember that you will need to add an entry to the “httpModules” section of your web.config (see below) which in a real world application would be done using the SPWebConfigModification class. However, as this is just a demo I have added it by hand to save myself sometime.

Now to allow Ninject to actually do it's dependency injection magic there are a few things you must do. The first of these is to modify the “AssemblyInfo.cs” file for all of your projects (well the ones using Ninject at least) so they will allow partially trusted callers. If you don't do this then a security exception is thrown when you inject your object into the Ninject kernel.

1: using System.Security;

2:

3: [assembly: AllowPartiallyTrustedCallers]

The next thing you need to do is inject the actual instance of the object you want Ninject to apply dependency injection to into the kernel you created. The way I did this was to create a number of base classes which inherit from commonly used items in SharePoint like Web Parts, User Controls and Application Pages. Then within the constructor for each base class I inject the instance of that object into the Ninject kernel.