c# - ASP.NET WebAPI 中的依赖注入(inject) : IHttpControllerActivator vs. IDependencyResolver

Question

最近我遇到了这个讨论。

在 ASP.NET WebAPI 中，当我们需要集成自定义控制反转/依赖注入(inject)容器时，我们需要采用两种不同的策略:

1. 实现 IHttpControllerActivator，它是完全控制 Controller 生命周期的扩展点。也就是说，我们可以定义一个 Controller 是如何被实例化的。此时，我们可以使用控制反转容器解析 Controller ，并让它使用自己的依赖注入(inject)方法。

2. 实现 IDependencyResolver，我们可以在其中定义如何解决依赖注入(inject)。

在我当前的项目中，我采用了 IHttpControllerActivator 方式，并且由于我使用 CaSTLe Windsor 作为控制容器的反转，我可以从其完全控制对象生命周期容器配置，我可以决定如何解析 Controller ，及其递归注入(inject)的依赖项的范围定义一旦 Controller 结束其生命(即请求结束时)它们就会死亡。

虽然其中一些功能可以通过 IDependencyResolver 实现来实现，但我认为 IHttpControllerActivator 是在 ASP.NET Web 中集成控制反转和依赖注入(inject)的最佳方式API，因为我相信我更喜欢尽可能抽象，并坚持在控制反转和依赖注入(inject)方面使用 CaSTLe Windsor 配置模型。

IHttpControllerActivator 方法的主要缺点是您需要在容器中注册所有 Controller ，而 IDependencyResolver 仍然负责将 Controller 解析给 ASP.NET Web API管道(对我来说，这不是什么大问题，我只是使用 CaSTLe Windsor 的 Classes.FromAssembly 来配置派生 ApiController 的所有 Controller ) .

我是否忽略了任何其他会使 IDependencyResolver 方法更合适的缺点？

Answer 1

IHttpControllerActivator 方法主要优于 IDependencyResolver 方法，因为它提供了上下文，如以下博客文章中所述:http://blog.ploeh.dk/2012/09/28/DependencyInjectionandLifetimeManagementwithASP.NETWebAPI/ .

但是，在大多数更简单的情况下，手动注册所有内容的额外努力根本没有返回。在许多情况下使用 IDependencyResolver 方法只是“成功”。添加良好的文档和更大的日常用户群，我自己可能会考虑是否可以在考虑 IHttpControllerActivator 之前使用 IDependencyResolver。