Web API 2和Configuration.DependencyResolver.GetService中的构造函数注入依赖项是否有任何区别？

Question

给出像这样的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，是否已经根据构造控制器调用了开始范围，或者我应该首先执行开始范围。

Answer 1

IoC.Resolve <>是服务定位器模式的示例。该模式强加了一些限制，这些限制是构造函数注入所不具备的：

1. 对象不能具有比应用程序更多的细粒度上下文 域，因为有静态调用
2. 对象决定要解决的依赖项版本。所有 某个类的实例将获得相同的依赖关系 配置。
3. 例如，将代码耦合到容器的诱惑很高 而不是创建一个意图公开工厂。
4. 单元测试需要容器配置，其中的类 只能被创建并以其他方式使用。 （尤其是 当您要测试的多个配置时比较麻烦 同一类，由于上述第二个问题。）
5. 不能从其公共API推断应用程序的结构。 （构造函数参数是一件好事。它们不是您的问题 应该感到需要解决。）

在我看来，这些限制使Service Locator模式处于泥潭和依赖注入之间的中间位置：如果必须使用它，则很有用，但到目前为止并不是最佳选择。