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 に答える