MEF（Managed Extensibility Framework）とIoC / DI
MEF（Managed Extensibility Framework）は、既存のIoC/DIコンテナーでは解決できない問題をどのように解決しますか？
MEFの主な目的は拡張性です。アプリケーションの作成者とプラグインの作成者（extension）が異なり、公開されたインターフェイス以外に互いの特定の知識がない場合の「プラグイン」フレームワークとして機能します（ 契約）ライブラリ。
MEFが対処するもう1つの問題は、通常のIoCの容疑者とは異なり、MEFの強みの1つは、[拡張]の発見です。拡張機能に関連付けることができるメタデータを操作する、多くの拡張可能な検出メカニズムがあります。 MEF CodePlexサイトから：
"MEFでは、拡張機能に追加のメタデータをタグ付けして、豊富なクエリとフィルタリングを容易にすることができます"
タグ付けされた拡張機能を遅延ロードする機能と組み合わせると、拡張機能のメタデータを問い合わせることができます前ロードすることで、多くの興味深いシナリオへの扉が開かれ、[プラグイン]バージョン管理などの機能が大幅に有効になります。
MEFには、拡張機能を「適応」または「変換」（タイプ>からタイプへ）して、これらの変換の詳細を完全に制御できる「コントラクトアダプタ」もあります。コントラクトアダプタは、「発見」が意味し、伴うものに関連して、別の創造的な前線を開きます。
繰り返しになりますが、MEFの「意図」は匿名のプラグインの拡張性に重点を置いており、他のIoCコンテナとは大きく異なります。したがって、MEFは構成に使用できますが、それは他のIoCと比較した場合の機能の小さな共通部分にすぎません。これにより、今後多くの近親相姦の相互作用が見られると思います。
IoCコンテナーは、ユーザーが知っていることに焦点を当てています。つまり、単体テストで1つのロガーを使用し、アプリで別のロガーを使用することを知っています。 MEFはあなたがしていないことに焦点を合わせています、私のシステムに現れるかもしれない1からnのロガーがあります。
スコット・ハンゼルマンと私は、最近のハンゼル議事録でこのトピックをより詳細に取り上げました。