WebAPI 2和Configuration.DependencyResolver.GetService中构造函数注入的

本文关键字：构造函数 注入 GetService DependencyResolver Configuration WebAPI | 更新日期: 2023-09-27 18:27:09

给定这样的webApi控制器：

public class MapsController : OwinApiController
{
    private readonly IStorageAccountCache _mapCache;
    public MapsController(IStorageAccountCache mapCache)
    {
        this._mapCache = mapCache;
        this._mapCache = Configuration.DependencyResolver.GetService(typeof(IStorageAccountCache)) as IStorageAccountCache
    }
}

这与通过配置访问依赖关系解析程序而不是从构造函数获取值有什么不同吗？

感兴趣的原因是，给定一个相当大的控制器，它有很多依赖项和许多只使用其中一个子集的操作，如果在那些只在特定操作中需要依赖项的操作中使用Configuration.DependencyResolver.GetService，我会考虑。

此外，如果执行Configuration.DependencyResolver.GetService，它是否已经根据构造控制器调用了开始作用域，或者我应该先执行开始作用域。

WebAPI 2和Configuration.DependencyResolver.GetService中构造函数注入的

IoC.Resolve<gt；是服务定位器模式的一个示例。这种模式施加了一些构造函数注入所没有的限制：

  1. 对象不能具有比应用程序更细粒度的上下文域，由于静态调用
  2. 对象决定要解析的依赖关系的版本。全部的某个类的实例将获得相同的依赖关系配置
  3. 例如，将代码耦合到容器的诱惑很高而不是创建一个意图暴露的工厂
  4. 单元测试需要容器配置，其中类可以创建并以其他方式使用。（这尤其当您想测试同一类，由于上面的第二个问题。）
  5. 无法从应用程序的公共API推断应用程序的结构。（构造函数参数是一件好事应该觉得有必要解决。）

在我看来，这些限制将ServiceLocator模式降级为介于大泥球和依赖注入之间的中间地带：如果必须使用它，它很有用，但迄今为止还不是最佳选择。

相关文章：