(I originally posted this on my MSDN blog.)
ASP.NET MVC 3 offers new facilities for easy dependency injection in various parts of the application that you might want to implement yourself. Brad Wilson discusses the new features in an extensive series of posts. In the Beta version and beyond, the way you do this is by creating a class that implements IDependencyResolver and serves as an adapter to the IoC container of your choice.
I happen to like StructureMap as an IoC container so I thought I ‘d wire it up for use in ASP.NET MVC 3. IDependencyResolver isn’t exactly a complex interface to implement but being the properly lazy developer that I am I thought I’d look around on the web to see if anyone had already offered up an implementation for StructureMap. I found a few different blog posts that all had pretty much the same code (such as Brandon Satrom’s) so I grabbed it and dropped it into my application. I then tried to have one of my controllers pulled from the container and . . . met with utter failure.
Specifically, StructureMap kept insisting that it had no idea what I was talking about when my IDependencyResolver adapter asked for an instance of my TitlesController (i.e. container.TryGetInstance(serviceType) was returning null). The framework would then fall back to trying to create an instance on its own which would throw an exception because this controller was designed for dependency injection and didn’t have a parameter-less constructor.
This was particularly aggravating because all the implementations I found on the web seemed to be the same and apparently they were working for other people. I beat my head against this problem for, um, longer than I should have, I guess, until I finally found a email thread started by Jimmy Bogard on the StructureMap users list that clarified the problem for me. The issue is that while StructureMap’s Container.GetInstance() will create an instance of a concrete type without it being explicitly registered, Container.TryGetInstance() doesn’t do that. Container.TryGetInstance() will give up and return null if the type you’re asking for isn’t explicitly registered as a plugin type. Coincidentally, the very first thing I was trying to pull out of the container was a concrete type (my controller class). The existing implementations will work for registered interfaces but not for controllers which are requested by concrete type.
By the way, while researching all of this I ran across this thread in which Jeremy Miller points out that the original implementation of of IDependencyResolver.GetServices was wrong, too.
So here’s my IDependencyResolver implementation for StructureMap which takes StructureMap’s non-intuitive behavior into account and also tries to minimize the number of exceptions that have to be thrown and handled:
(UPDATE: I removed some registration code from the constructor that was causing confusion and probably wasn’t necessary (at least not for resolving concrete controller types, anyway.) If you need to resolve interface types, you’ll need to register them with StructureMap in your app’s registration code or maybe do it below in the constructor.)
public class StructureMapDependencyResolver : IDependencyResolver
{
readonly IContainer _container;
public StructureMapDependencyResolver(IContainer container)
{
_container = container;
// TODO: if you haven't registered necessary interfaces somewhere else, you'll need to do so here.
}
public object GetService(Type serviceType)
{
if (serviceType.IsClass)
{
return GetConcreteService(serviceType);
}
else
{
return GetInterfaceService(serviceType);
}
}
private object GetConcreteService(Type serviceType)
{
try
{
// Can't use TryGetInstance here because it won’t create concrete types
return _container.GetInstance(serviceType);
}
catch (StructureMapException)
{
return null;
}
}
private object GetInterfaceService(Type serviceType)
{
return _container.TryGetInstance(serviceType);
}
public IEnumerable<object> GetServices(Type serviceType)
{
return _container.GetAllInstances(serviceType).Cast<object>();
}
}
SaintGimp 