0

假设我使用的是 IoC 容器，为什么我的类型必须注入它们的依赖项？为什么不能每种类型都假设容器存在并只检索它自己需要的依赖项？后一种方法有什么缺点？

我知道属性注入，但我不希望将其作为答案，即使它确实节省了在更复杂类型中使用长参数列表构造函数。这并没有节省您最终需要键入/维护的代码。哦，我更喜欢只读/最终的依赖项（个人喜好）。

下面是一个典型的 C# 构造函数注入示例：

public class Calculator
{
    private readonly IAdder _adder;
    private readonly ISubtractor _subtractor;
    private readonly IMultiplier _multiplier;
    private readonly IDivider _divider;

    public Calculator(IAdder adder, ISubtractor subtractor,
                      IMultiplier multiplier, IDivider divider)
    {
        _adder = adder;
        _subtractor = subtractor;
        _multiplier = multiplier;
        _divider = divider;
    }
}

这就是我宁愿做的事情：

public class Calculator
{
    private readonly IAdder _adder;
    private readonly ISubtractor _subtractor;
    private readonly IMultiplier _multiplier;
    private readonly IDivider _divider;

    public Calculator()
    {
        _adder = Container.Get<IAdder>();
        _subtractor = Container.Get<ISubtractor>();
        _multiplier = Container.Get<IMultiplier>();
        _divider = Container.Get<IDivider>();
    }
}

随着答案的出现，我想保留一份利弊清单：

优点

  • 干净的构造函数作为类型不需要“污染”它们的构造函数的依赖关系。这不是一个大问题，因为 Calculator 在其构造函数中除了依赖项之外没有任何东西，但想象一下它确实存在。例如public Calculator(Mode mode, bool UseDigitGrouping)。
  • 当依赖项的依赖项发生更改时，客户端代码不会中断。
  • 需要维护的代码更少。

缺点：

  • 将来更难更改 IoC 容器。
  • 目前尚不清楚类型的依赖项是什么。
4

1 回答 1

1

假设我使用的是 IoC 容器，为什么我的类型必须注入所有依赖项？为什么不能每种类型都假设容器存在并只检索它自己需要的依赖项？这样做有什么缺点？

我能想到的几个原因，你提到了一个：

  • 如果有的话，你的类有什么依赖已经不再明显了
  • 该类将假定对容器具有隐藏的依赖关系，至少是最坏的一种（假设它作为全局存在或可静态访问）

您对在依赖项的依赖项更改有效时调整代码的难易程度的担忧；这对 IoC 来说是一个非常有力的论据（让容器自动为你做这件事；只要可以满足所有依赖关系，什么都不会破坏）。

于 2012-06-30T17:17:06.850 回答