配置依赖注入的ASP.NET Web API 2.1 [英] Configuring dependency injection with ASP.NET Web API 2.1

问题描述

我创建一个ASP.NET Web API 2.1的网站，因为我想直接把依赖注入控制器中，我创建了自己实施的IDependencyResolver，使StructureMap将处理为我。

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()
    {
    }
}

我再叫的Web API中加入这一行到Global.asax中的Application_Start方法

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();

这是编译的，但是当我试图访问在浏览器中的任何API方法我得到了这样的错误。

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

这一次是比较容易解决，因为我添加了一行到我的StructureMap配置

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

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

但后来我得到其他类似的错误对其他System.Web.Http类，虽然我可以解决其中的一些，我被困在如何处理与他们的3，即ITraceManager，IExceptionHandler和IContentNegotiator。

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.

问题是TraceManager这似乎是ITraceManager的默认实现是一个内部类，所以我不能引用它在我的StructureMap配置。

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?

推荐答案

我想给你一个建议，并解释为什么不走这条路，以及如何以不同的方式做到这一点（我甚至会说好，妥善）。

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).

不恰当的的IDependencyResolver 设计的全面和完整的解释可能在这里找到：<一href=\"http://blog.ploeh.dk/2012/09/28/DependencyInjectionandLifetimeManagementwithASP.NETWebAPI/\">Dependency注入和生存期管理与马克·塞曼的ASP.NET Web API

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:

用的IDependencyResolver问题

与的IDependencyResolver 的主要问题是，它本质上是一个的服务定位器的。有许多问题与的服务定位器的反模式，但其中大部分我已经在这个博客上其他地方描述（在我的书）。服务定位器的一个缺点，我还没有写那么多的是，每​​次调用GetService的范围内有没有上下文的。这是与服务定位器的反模式，而不是仅仅用的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.

和也：

...依赖图需要知道一些关于上下文。什么是请求的URL？什么是基地址（主机名等）请求？你怎么能在单个请求中共享的依赖实例？为了回答这些问题，你必须了解的背景下，和的IDependencyResolver不提供这些信息。

...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.

在短，的IDependencyResolver 不是组成的依赖关系图右曲球。 *的幸运的是，的ASP.NET Web API具有用于此目的的更好的扩展点。 * 的

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 。请看看这个答案：

ServiceActivator

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

• 的WebAPI + APIController与structureMap

• WebAPI + APIController with structureMap

的例子在 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;
    }
}

我们所用StructureMap做的，很到位。在Web API框架的主要特点依然存在......我们没有砍他们。而我们也相当使用DI /国际奥委会然后服务定位器

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

这篇关于配置依赖注入的ASP.NET Web API 2.1的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持IT屋！