Configuring dependency injection with ASP.NET Web API 2.1

Question

I'm creating an ASP.NET Web API 2.1 site and as I want to inject dependencies directly into the controllers, I've created my own implementation of IDependencyResolver so that StructureMap will handle that for me.

public class StructureMapDependencyResolver : IDependencyResolver {     public IDependencyScope BeginScope()     {         return this;     }      public object GetService(Type serviceType)     {         return ObjectFactory.GetInstance(serviceType);     }      public IEnumerable<object> GetServices(Type serviceType)     {                     return ObjectFactory.GetAllInstances(serviceType).Cast<object>();     }      public void Dispose()     {     } } 

I've then told Web API to use this class by adding this line to the Application_Start method in Global.asax

GlobalConfiguration.Configuration.DependencyResolver = new StructureMapDependencyResolver(); 

That compiled but when I tried to access any of the API methods in a browser I got an error like this

No Default Instance defined for PluginFamily System.Web.Http.Hosting.IHostBufferPolicySelector, System.Web.Http 

That one was relatively easy to solve as I added a line to my StructureMap configuration

this.For<IHostBufferPolicySelector>().Use<WebHostBufferPolicySelector>(); 

However then I got other similar errors for other System.Web.Http classes and while I could resolve some of them I am stuck on how to deal with 3 of them, namely ITraceManager, IExceptionHandler and IContentNegotiator.

The issue is that TraceManager which seems to be the default implementation of ITraceManager is an internal class and so I can't reference it in my StructureMap configuration.

So am I going about this completely the wrong way or is there some other way to inject these internal classes?

Answer 1

I'd like to give you a suggestion and explanation why not to go this way, and how to do it differently (I'd even say better and properly).

The full and complete explanation of the inappropriate IDependencyResolver design could be found here: Dependency Injection and Lifetime Management with ASP.NET Web API by Mark Seemann

Let me cite these essential parts:

The problem with IDependencyResolver

The main problem with IDependencyResolver is that it's essentially a Service Locator. There are many problems with the Service Locator anti-pattern, but most of them I've already described elsewhere on this blog (and in my book). One disadvantage of Service Locator that I haven't yet written so much about is that within each call to GetService there's no context at all. This is a general problem with the Service Locator anti-pattern, not just with IDependencyResolver.

And also:

...dependency graph need to know something about the context. What was the request URL? What was the base address (host name etc.) requested? How can you share dependency instances within a single request? To answer such questions, you must know about the context, and IDependencyResolver doesn't provide this information.

In short, IDependencyResolver isn't the right hook to compose dependency graphs. **Fortunately, the ASP.NET Web API has a better extensibility point for this purpose. **

ServiceActivator

So, the answer in this scenario would be the ServiceActivator. Please take a look at this answer:

• WebAPI + APIController with structureMap

An example of the ServiceActivator:

public class ServiceActivator : IHttpControllerActivator {     public ServiceActivator(HttpConfiguration configuration) {}          public IHttpController Create(HttpRequestMessage request         , HttpControllerDescriptor controllerDescriptor, Type controllerType)     {         var controller = ObjectFactory.GetInstance(controllerType) as IHttpController;         return controller;     } } 

All we can do with StructureMap, is in place. The key features of the Web API framework are still in place... we do not have to hack them. And we are also rather using DI/IoC then Service locator