dependency-injection - このioc動作の背後にある理由は何ですか（複数の登録済みコンポーネントで解決）

Question

（C＃windsor）のようなシナリオが与えられた場合、iocの標準的なアプローチのように見えます。

container.AddComponent<ILogger, HttpLogger>();
container.AddComponent<ILogger, SmtpLogger>();

var logger = container.Resolve<ILogger>();

コンポーネントを解決するとき、最初に登録されたILogger（この場合はHttpLogger）が解決の唯一の候補であり、iocは、すべての依存関係を解決できると信じる場所で「最も太い」コンストラクターを見つけます。

ただし、iocが最初のロガーの依存関係を解決できない可能性があり、したがって解決の問題が返されます。iocが試行した場合、SmtpLoggerが解決された可能性があります。

では、最初に登録されたサービスのみを候補として使用する理由は何ですか？どのタイプを取得するかは議論の余地があるようですが、とにかく使用するコンストラクターはiocが担当します。

では、適用可能なすべての型のすべてのコンストラクターから選択して、最も太いコンストラクターから（実際の型にとらわれずに）解決しようと試みてみませんか？

これは本当に明白な答えがあるかもしれませんが、正直なところ私はそれを知りません。

スティーブン、よろしくお願いします。

score 2 · Accepted Answer

この理由は、実装の複雑さへの影響です。

この種の動作を実装すると、再帰的に機能することがわかります。たとえば、ロガーの1つの依存関係が満たされるかどうかを判断するには、そのすべての依存関係をウォークダウンする必要があります。

これを効率的に行うことは困難であり、コンテナとデバッグエクスペリエンスに多くの複雑さを追加します。

MEFは、厳密にはIoCコンテナーではありませんが、提案したのと同様の方法でこれを実行します。これは、安定した構成の動作の一部であり、「拒否」と呼ばれます。

非常に動的なプラグインシナリオでは、拒否は非常に役立ちます。Windsor、Autofacなどが対象としているシナリオでは、追加の努力はそれほど報われません。

1 に答える 1