使用ASP.NET Web API 2.1配置依赖注入

发布时间：2020-12-15 18:50:04 所属栏目：asp.Net 来源：网络整理

导读：我创建一个ASP.NET Web API 2.1网站，因为我想注入依赖项直接到控制器，我创建了我自己的IDependencyResolver的实现，以便StructureMap将为我处理。 public class StructureMapDependencyResolver : IDependencyResolver{ public IDependencyScope BeginScop

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

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方法来使用此类

GlobalConfiguration.Configuration.DependencyResolver = new StructureMapDependencyResolver();

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

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

这是一个相对容易解决，因为我添加一行到我的StructureMap配置

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

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

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

所以我是完全错误的方式，还是有其他方式来注入这些内部类？

解决方法

我想给你一个建议和解释，为什么不这样做，以及如何做不同的(我甚至会说得更好和正确)。

对不适当的IDependencyResolver设计的完整和完整的解释可以在这里找到：Dependency Injection and Lifetime Management with ASP.NET Web API通过Mark Seemann

让我引述这些重要部分：

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.

并且：

…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

因此，在这种情况下的答案将是ServiceActivator。请看看这个答案：

> 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 / IoC然后Service定位器

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!