（C＃ウィンザー）のようなシナリオが与えられたとき、IOCのための標準的なアプローチのように思える

Question

（複数登録コンポーネントと解決）本IOC現象の背後にある理由は何ですか：

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

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

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

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

最初に登録したサービスだけを候補として使用する理由は何ですか？どちらのタイプの不確実性が議論であると思われますが、とにかくどのコンストラクタを使用するのかをiocに任せています。

なぜ、該当するすべてのタイプのすべてのコンストラクタを選んで、最もファクトなコンストラクタから（実際のタイプには無関係に）解決しようとしないのですか？

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

ありがとうございます。 Stephen。

Answer 1

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

この種の動作が実装されると、再帰的に動作することがわかります。ロガーのいずれかの依存関係を満たすことができるかどうかを調べるには、のの依存関係のすべてを調べる必要があります。

これを効率的に実行することは難しく、コンテナとデバッグ環境に多くの複雑さが加わります。

MEFは厳密にはIoCコンテナではありませんが、これはあなたが提案したのと同じ方法で行います。これはStable Compositionの動作の一部で、拒否と呼ばれます。高ダイナミックプラグインシナリオで

http://blogs.msdn.com/nblumhardt/archive/2009/07/17/light-up-or-mef-optional-exports.aspx

、拒絶反応は極めて有用です。ウィンザー、オートファックなどがターゲットとしているシナリオでは、追加された努力はあまり効果がありません。