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

Question

最近我遇到了这个讨论。

在ASP.NET的WebAPI，当我们需要整合控制/依赖注入容器的自定义反转，我们需要去用两种不同的策略：

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

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

在我目前的项目，我去了IHttpControllerActivator路，因为我使用温莎城堡作为控制容器的反转，我完全可以从它的容器配置控制对象的生命周期，我可以决定如何控制器被解决，并且其递归注入的依赖性的范围定义了它们在控制器结束其生命（即，当请求结束时）时死亡。尽管其中一些功能可以通过IDependencyResolver实现来实现，但我认为IHttpControllerActivator是集成ASP.NET Web API中的控件和依赖注入反转的最佳方式，因为我相信我更喜欢保持抽象在控制和依赖注入的反演方面可能并坚持Castle Windsor配置模型。

与IHttpControllerActivator方法的主要缺点是，你需要注册容器中的所有控制器同时IDependencyResolver仍然给出解决控制器的ASP.NET Web API管线（我的责任，这并没有受到大的问题，我只是使用Castle Windsor的Classes.FromAssembly来配置所有控制器派生ApiController）。

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

Answer 1

的IHttpControllerActivator方法主要具有超过因为提供的上下文的IDependencyResolver方法的优点，如在下面的博客文章描述极好：http://blog.ploeh.dk/2012/09/28/DependencyInjectionandLifetimeManagementwithASP.NETWebAPI/。

但是，在最简单的情况下，它不会付出额外的努力来手动注册所有内容。在许多情况下使用IDependencyResolver方法只是“做窍门”。添加良好的文档和更大的日常用户群，我自己可能会考虑是否可以在考虑IHttpControllerActivator之前使用IDependencyResolver进行管理。