I’ve had the opportunity to tinker in the depths of the WebAPI in Sitecore 7.5 and 8 recently. I’ll put up a post about setting up controllers easily shortly but until then I thought I’d share how to setup IOC.
In a normal WebAPI environment, we can create our resolver and attach it to the GlobalConfiguration. However, we must remember that Sitecore uses its own pipelines for MVC and WebAPI and so setting this up in the Global ASAX won’t work.
The way I’ve done it is to change the registered WebAPI initialiser class in the Sitecore.Services.Config file found in App_Config/Include. This lets me hook directly into the entry point for Sitecore related WebAPI and adjust the configuration accordingly.
EDIT: This post covers versions pre Sitecore 8.1.
In this post I will be describing pulling your controllers for use in controller renderings from an IoC container, in this case (again) Castle Windsor. The principle would apply to most containers in the same manner.
In my on-going quest to avoid the ‘new’ keyword in my Sitecore implementations, well – in fact more just to delegate the responsibility of dependency management to my IoC container. I remembered that we had pulled together from a few internet sources, a set of classes that allow the instantiation of Controllers from our IoC container. I wish I could credit the internet sources, but sadly as lazy developers, we gladly consumed and dutifully discarded them. I would also like to add that this was the collaboration of a couple of developers to finalise this solution, so not all my own handiwork on this occasion.
So – here is the second in the series of introducing Agnostic IoC. In this topic I wanted to cover a standard problem that (particularly as developers of a proprietary system such as Sitecore) face regularly.
I have always (for convenience as much as anything) utilised the global.asax.cs to perform my container setup. This is particularly easy as I usually have this class inherit an interface. This conveniently allows me to cast the application instance as my ‘IContainerAccessor’ to allow me to get at the container. This (for Sitecore / Umbraco) in particular is inherently flawed in that, the vendors of third party systems also often mess with these classes – Sitecore for example (off the top of my head) have changed it in 2 or 3 of the last major releases and possibly some of the minors. I have seen (in implementations such as Glass Mapper), the use of WebActivator to overcome this too – this is a perfectly reasonable alternative.
In designing Agnostic IoC, I wanted to consider the possibility of having Agnostic scan the loaded assemblies for containeradapters and register them for itself, here is an example of the test container adapter we are going to use.
Just a quick post to announce, the initial release candidate for Agnostic IoC is now available on the Cardinal Nightly Feed (soon to be Nuget)
The initial release provides support for the following IoC containers:
- Castle Windsor
- StructureMap (experimental at present)
Support for other containers can easily be added by creating a class deriving from the ContainerAdapter class and overriding the necessary methods. Use one of the existing ContainerAdapters as an example.
The nuget packages can currently be found on the Cardinal Nightlies Nuget Feed
The source code can be found here Cardinal Github Page
So – in this post I will cover my latest (and somewhat marmite) solution to the issue of managing dependencies when your clients insist you use the IoC container of their choice.
Many times in my development career I have had to switch the use of IoC containers due to the client having defined standards on what they would like you to use. So far, I have already had the opportunity to implement sites using Autofac, Ninject, Windsor & Unity. I fully expect there will be more!
In addition to this, I have a number of modules now available that I have deliberately avoided using a DI framework due to the above (it is a personal bug bear of mine for example that Sitecore’s social connect module ships with Ninject).
For all of the reasons above – I have created Agnostic IoC. It is a simple module that handles the instantiation of IoC containers and allows your code to rely on its own IContainerManager to resolve your dependencies.
Some time ago I decided that Autofac was my IOC of choice. After spending a few years using Unity I knew I wanted more and, after evaluating a few libraries, Autofac fitted how I work.
Aside from the usual property and constructor injection stuff we would expect from any IOC library, Autofac has quite a few additional features that can make coding life a lot easier. And in less lines of code.
One thing I love to show people who have used IOC for a while is my use of delegate factories.
The wiki post from the Autofac project is here: https://github.com/autofac/Autofac/wiki/Delegate-Factories.
I think the title says it all!
Let components create instances of other components without hand-coding factories.
So, in short, we can use Autofac as a factory and take a dependency on that factory instead of the type itself. This is quite powerful as it means we can create instances of our dependency within our component as needed.
Ever wondered how to resolve your command / pipeline entry from your IoC container? One of the more common arguments I have seen for the Service Locator (anti) pattern is for exactly this reason, and it’s completely avoidable. This approach works perfectly well with the likes of Castle Windsor, Autofac, Unity or even Agnostic IoC. This also provides the added bonus of being able to unit test your pipelines, which in my humble opinion is possibly where it is needed most. It also allows you to utilise constructor injection in Sitecore Pipelines (which I have heard from seasoned Sitecore developers can’t be done 😉 ).
In this post I describe how to give control of your dependencies on pipeline & commands to your IoC container of choice using Sitecore factories.