Mat*_*zer 5 .net c# asp.net dependency-injection asp.net-web-api
最近我遇到了这个讨论.
在ASP.NET WebAPI中,当我们需要集成控件/依赖注入容器的自定义反转时,我们需要采用两种不同的策略:
实现IHttpControllerActivator,这是一个完全控制控制器生命周期的扩展点.也就是说,我们可以定义控制器的实例化方式.此时,我们可以使用控件容器的反转来解析控制器,并让它使用自己的依赖注入方法.
实现IDependencyResolver,我们可以在其中定义如何解决依赖注入.
在我目前的项目中,我IHttpControllerActivator顺便说一句,因为我使用Castle Windsor作为控制容器的反转,我可以从容器配置中完全控制对象生命周期,我可以决定如何解析控制器,以及递归的范围注入的依赖关系定义一旦控制器结束其生命(即请求结束时)它们就会死亡.
虽然这些功能中的一些可以通过实现来IDependencyResolver实现,但我觉得这IHttpControllerActivator是在ASP.NET Web API中集成控件和依赖注入的反转的最佳方式,因为我相信我更喜欢保持尽可能抽象并坚持使用Castle Windsor在控制和依赖注入的反转方面的配置模型.
这种IHttpControllerActivator方法的主要缺点是你需要在容器中注册所有控制器,同时IDependencyResolver仍然负责将控制器解析为ASP.NET Web API管道(对我来说,这不是一个大问题,我只是使用Castle Windsor的Classes.FromAssembly配置所有控制器派生ApiController).
我是否会忽略任何其他可能使该IDependencyResolver方法更合适的缺点？
该IHttpControllerActivator方法相对于该方法的优势主要IDependencyResolver在于所提供的上下文，如以下博客文章中所述： http: //blog.ploeh.dk/2012/09/28/DependencyInjectionandLifetimeManagementwithASP.NETWebAPI/。
然而，在大多数更简单的情况下，手动注册所有内容并不会带来额外的努力。在许多情况下使用 IDependencyResolver 方法只是“奏效”。添加良好的文档和更大的日常用户群，我自己可能会考虑IDependencyResolver在考虑之前是否可以管理使用IHttpControllerActivator。