ASP.NET WebAPI中的依赖注入：IHttpControllerActivator与IDependencyResolver

Question

最近我遇到了这个讨论。

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

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

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

在我目前的项目中，我采用IHttpControllerActivator方式，因为我使用 Castle Windsor 作为控件容器的反转，我可以从容器配置中完全控制对象生命周期，我可以决定如何解析控制器，以及递归注入的依赖关系的范围，定义一旦控制器结束其生命（即请求结束时）它们就会死亡。

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

IHttpControllerActivator方法的主要缺点是您需要在容器中注册所有控制器，而IDependencyResolver仍然负责将控制器解析为ASP.NET Web API管道（ for我，这不是一个大问题，我只是使用Castle Windsor的Classes.FromAssembly来配置派生ApiController 的所有控制器。）

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

Answer 1

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

但是，在大多数情况下，它根本不会支付手动注册所有内容的额外费用。在许多情况下使用IDependencyResolver方法只是“诀窍”。添加好的文档和更大的日常用户群，我自己可能会考虑在考虑IDependencyResolver之前是否可以使用IHttpControllerActivator进行管理。