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管道（ 對我來說，這不是一個大問題，我只是用過Castle Windsor的Classes.FromAssembly配置所有控制器派生ApiController ）。

我是否忽略了使IDependencyResolver方法更IDependencyResolver任何其他缺點？

Answer 1

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

但是，在大多數情況下，它根本不會回報手動注冊所有內容的額外工作。 在許多情況下使用IDependencyResolver方法只是“訣竅”。 添加好的文檔和更大的日常用戶群，我自己可能會考慮在考慮IHttpControllerActivator之前是否可以使用IDependencyResolver進行管理。