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

前端之家收集整理的这篇文章主要介绍了使用ASP.NET Web API 2.1配置依赖注入前端之家小编觉得挺不错的,现在分享给大家,也给大家做个参考。
我创建一个ASP.NET Web API 2.1网站,因为我想注入依赖项直接到控制器,我创建了我自己的IDependencyResolver的实现,以便StructureMap将为我处理。
  1. public class StructureMapDependencyResolver : IDependencyResolver
  2. {
  3. public IDependencyScope BeginScope()
  4. {
  5. return this;
  6. }
  7.  
  8. public object GetService(Type serviceType)
  9. {
  10. return ObjectFactory.GetInstance(serviceType);
  11. }
  12.  
  13. public IEnumerable<object> GetServices(Type serviceType)
  14. {
  15. return ObjectFactory.GetAllInstances(serviceType).Cast<object>();
  16. }
  17.  
  18. public void Dispose()
  19. {
  20. }
  21. }

然后我告诉Web API通过将此行添加到Global.asax中的Application_Start方法来使用此类

  1. GlobalConfiguration.Configuration.DependencyResolver = new StructureMapDependencyResolver();

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

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

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

  1. 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的一个示例:

  1. public class ServiceActivator : IHttpControllerActivator
  2. {
  3. public ServiceActivator(HttpConfiguration configuration) {}
  4.  
  5. public IHttpController Create(HttpRequestMessage request,HttpControllerDescriptor controllerDescriptor,Type controllerType)
  6. {
  7. var controller = ObjectFactory.GetInstance(controllerType) as IHttpController;
  8. return controller;
  9. }
  10. }

我们可以用StructureMap做的,就是到位。 Web API框架的关键特性仍然存在…我们不必黑客攻击它们。我们也使用DI / IoC然后Service定位器

猜你在找的asp.Net相关文章