MEF(Managed Extensibility Framework)は、既存のIoC / DIコンテナーでは解決できない問題をどのように解決しますか?
3 に答える
MEF の主な目的は拡張性です。アプリケーションの作成者とプラグイン ( extension ) の作成者が異なり、公開されたインターフェース ( contract ) ライブラリを超えてお互いについて特別な知識がない場合の「プラグイン」フレームワークとして機能します。
通常の IoC 容疑者とは異なり、MEF が対処するもう 1 つの問題空間であり、MEF の強みの 1 つは、[拡張] の検出です。拡張機能に関連付けることができるメタデータで動作する、拡張可能な検出メカニズムが多数あります。MEF CodePlex サイトから:
「MEF を使用すると、拡張機能に追加のメタデータをタグ付けして、豊富なクエリとフィルタリングを容易にすることができます」
タグ付けされた拡張機能を遅延ロードする機能と組み合わせると、ロードする前に拡張機能のメタデータを調べることができるため、多くの興味深いシナリオへの扉が開かれ、[プラグイン] バージョン管理などの機能が大幅に有効になります。
MEFには、これらの変換の詳細を完全に制御して、拡張機能を ( type > から type に) '適応' または '変換' できるようにする 'Contract Adapters' もあります。コントラクト アダプターは、「発見」が何を意味し、何を必要とするかに関して、別の創造的な前線を開きます。
繰り返しになりますが、MEF の「意図」は、匿名プラグインの拡張性に重点を置いており、他の IoC コンテナーと大きく異なる点です。したがって、MEF は構成に使用できますが、それは他の IoC と比較して、その機能の小さな共通点にすぎません。今後、多くの近親相姦の相互作用が見られるのではないかと思います。
IoC コンテナーは、あなたが知っていることに焦点を当てています。つまり、単体テストで 1 つのロガーを使用し、アプリで別のロガーを使用することを知っています。MEF は、あなたが知らないことに焦点を当てています。私のシステムには 1 から n 個のロガーが表示される可能性があります。
Scott Hanselman と私は、最近の hanselminutes でこのトピックについて詳しく説明しました。