単純なケース: 次のように、メッセージをログに記録するためのインターフェイスがあります。
public interface ILogger
{
void Log(string message);
}
そして、おそらく 3 つの異なるクラスがこのインターフェースを実装しています。
これで、DI の 1 行に次のように書くことができます。
kernel.Bind<ILogger>().To<ConsoleLogger>();
私の質問は、多くのクラスでそのインターフェイスを使用する方法ですが、コンストラクターを介して全員に注入することはありません。使用したい非常に多くの異なるインターフェイスを持つことができ、そのクラスコンストラクターの宣言が面倒になる可能性があるためです。
コンストラクターに注入されたアイテムが多すぎると、コードの匂いがします。これは通常、クラスが複数の役割を果たしていることを意味します。単一の責任の原則は、各クラスがそのクラスに完全にカプセル化された 1 つの目的のみを持つべきであると述べています。
依存性注入では、レガシーシナリオの外部でプロパティ注入を使用することは不適切な形式と見なされます。プロパティを介して値を挿入することは、そのオプションを示唆しているため、実際には依存関係ではありません。
コンストラクターの依存関係がたくさんあるタイプがある場合は、リファクタリングを行う必要があることを示唆している可能性があります。おそらく、いくつかのタイプは一緒に使用され、独自のコンポーネントにリファクタリングすることができます。いずれにせよ、NinjectなどのIoCフレームワークを使用している場合、型が取るコンストラクターパラメーターの数は本当に重要ですか？コンテナは、関係なく注入を行います。
@LukeMcGregorが一般的に言っていることは真実ですが、ロガーは横断的関心事のように見えます。また、すべてのコンストラクターをILoggerで汚染したくない場合は、AOPを介して解決することもできます。Ninjectは、ninject.extensions.interceptionを介してAOPをサポートしているようです。
クラスにプロパティを実装し、ILogger Logger { get; set;}ほとんどの IoC コンテナがサポートするプロパティ インジェクション機能を使用できます。