Safe Dependency Injection for MVC and WebApi within Sitecore

Category: Sitecore Tags: dependency injection, mvc, sitecore, webapi 17 Comments

This post describes how we’ve considered approaching dependency injection with Sitecore at Hedgehog Development.
Many people have posted about dependency injection in Sitecore before, and each has had their own twist.

We’ve noticed that sometimes Sitecore controllers are failing to be resolved when there is a custom Dependency Resolver added.
The problem, as described in Mickey’s first post, is that MVC only allows for one DependencyResolver. So the moment you set your own Dependency Resolver, whatever was set there before (like whatever Sitecore set as the Dependency Resolver) will no longer work.
Because of this, Sitecore’s registered types will no longer get resolved, and you might see the following errors in the logs when you try to access one of the out-of-the-box Sitecore applications.

Exception: Sitecore.Mvc.Diagnostics.ControllerCreationException
Message: Could not create controller: 'Settings'.
The current route url is: 'api/sitecore/{controller}/{action}'. 
Source: Sitecore.Mvc
   at Sitecore.Mvc.Controllers.SitecoreControllerFactory.CreateController(RequestContext requestContext, String controllerName)

Message: No component for supporting the service Sitecore.Controllers.SettingsController was found

I spoke to Charlie Turano about this, and our solution was to create a ChainedMvcResolver, which will set a ‘Fallback Resolver’ to whatever the resolver was before we came along and set ours.

Then if our resolver can’t resolve the type, we’ll fallback and see if the fallback resolver can.
In this scenario, the fallback resolver will be what Sitecore set, so when we come across a SitecoreController, we don’t resolve it, and instead we leave it up to that DependencyResolver to figure out what it is.

    IDependencyResolver _fallbackResolver;
    IDependencyResolver _newResolver;
 
    public ChainedMvcResolver(IDependencyResolver newResolver, IDependencyResolver fallbackResolver)
    {
        _newResolver = newResolver;
        _fallbackResolver = fallbackResolver;
    }
 
    public object GetService(Type serviceType)
    {
        object result = null;
 
        result = _newResolver.GetService(serviceType);
        // Note: we assume the resolver returns null for unregistered types. This was found to perform better than
        // catching an exception, however this code could easily be modified to support a catch instead.
        if (result != null)
        {
            return result;
        }
 
        return _fallbackResolver.GetService(serviceType);
    }

To use it, we just create a new ChainedMvcResolver, passing in our resolver, and whatever DependencyResolver was previously set.

IDependencyResolver chainedMVCResolver = new ChainedMvcResolver(new WindsorMvcDependencyResolver(container),
                                                                    System.Web.Mvc.DependencyResolver.Current);
System.Web.Mvc.DependencyResolver.SetResolver(chainedMVCResolver);

This chaining method has been used before, but by chaining the ControllerFactory. Here, we’re just chaining the resolver instead.
The resolver issue has been seen before, and the idea of letting resolving the type elsewhere is not new. Chris van de Steeg’s SitecoreResolver in his BoC framework explicitly calls the Activator to create an instance. Similarly, in Mickey’s post above, he falls back by explicitly calling Sitecore.Mvc.Helpers.TypeHelper.CreateObject<IController> to get Sitecore to resolve it.

This certainly works, but the ChainedMvcResolver doesn’t assume the type passed in is a Controller, nor does it assume that Sitecore, (or anyone else) will be the one who should resolve it.

A note on ControllerFactories

Mickey posted how Sitecore changed how Dependency Injection was changed in Sitecore 8.1. Because the resolver is now being utilized, we can use the above fallback, and no longer need to create our own ControllerFactory for Sitecore to be able to resolve it’s own controllers.
This is fantastic, but be warned, if you’re using CastleWindsor as your DependencyResolver, you could potentially be causing memory leaks. (Thanks to Mike Edwards for the tip). In that case….maybe you should keep the Controller Factory, and release the controller correctly.

The WebApi Dependency Resolver Needs Attention Too

That’s right…. MVC and WebApi use different dependency resolvers.

However, the issue descibed above has also been noticed for WebApi with similar symptoms.
Brainjocks – WebAPI, SimpleInjector and AnalyticsDataController

In Pavel’s post above, the AnalyticsDataController was the one SimpleInjector struggled with (because it has multiple constructors).
But it made me wonder, what if there are other problematic Controllers in Sitecore’s code that mightn’t also get resolved properly with a custom DependencyResolver.

Again, we can do the chaining of DependencyResolvers for WebApi, the same way we did for MVC above.

IDependencyResolver chainedWebAPIResolver = new ChainedWebApiResolver(new WindsorWebApiDependencyResolver(container),
                                                                          GlobalConfiguration.Configuration.DependencyResolver);
System.Web.Http.GlobalConfiguration.Configuration.DependencyResolver = chainedWebAPIResolver;

Note: Full implementation is given in the github repo link below.

Now Sitecore Controllers, either MVC or WebApi, can continue to be resolved the way Sitecore intends, and our controllers be be resolved then way we want them to.

Please see the full implementation on our GitHub repo.
https://github.com/HedgehogDevelopment/sitecore-chained-dependency-resolver

Please let me know what you think about this approach? Is there anything you like/hate/would do differently?