Microsoft の Managed Extensibility Framework (MEF) とさまざまな IoC コンテナー (Unity など) を見ると、あるタイプのソリューションを別のタイプのソリューションよりも優先して使用するタイミングがわかりません。より具体的には、MEF はほとんどの IoC タイプ パターンを処理し、Unity のような IoC コンテナーは必要ないように思われます。
理想的には、MEF の代わりに、または MEF に加えて、IoC コンテナーが使用される適切なユース ケースを見たいと考えています。
要約すると、主な違いは、IoC コンテナーは一般に静的依存関係 (コンパイル時に既知) で最も有用であり、MEF は一般に動的依存関係 (実行時にのみ既知) で最も有用であることです。
このように、どちらも合成エンジンですが、パターンごとに重点が大きく異なります。したがって、MEF は既知のパーツの登録ではなく、未知のパーツの発見を中心に最適化されるため、設計上の決定は大きく異なります。
次のように考えてみてください。アプリケーション全体を開発している場合は、IoC コンテナーがおそらく最適です。サードパーティの開発者がシステムを拡張するなど、拡張性のために書いている場合は、おそらく MEF が最適です。
また、@Pavel Nikolov の回答の記事には、優れた方向性が示されています (MEF のプログラム マネージャーである Glenn Block によって書かれています)。
私はしばらくの間 MEF を使用してきましたが、IOC 製品の代わりに MEF を使用する際の重要な要素は、特定のインターフェイスの 3 ～ 5 個の実装が、特定の時間にプラグイン ディレクトリに常駐していることです。これらの実装のどれを使用する必要があるかは、実際には実行時にのみ決定できるものです。
MEF は、まさにそれを可能にします。通常、IOC は、将来のある時点で、ORM Product 1 に基づく IUserRepository を ORM Product 2 に交換できるようにすることを目的としています。ただし、ほとんどの IOC ソリューションでは、特定の時点で有効な IUserRepository は 1 つだけであると想定しています。
ただし、特定のページ リクエストの入力データに基づいていずれかを選択する必要がある場合、通常、IOC コンテナーは途方に暮れます。
例として、私がしばらく取り組んでいる大きな Web アプリの MEF プラグインを介して、アクセス許可のチェックと検証を行います。MEF を使用して、レコードの CreatedOn 日付を確認し、レコードが作成されたときに実際に有効だった検証プラグインを探し、そのプラグインと現在有効なバリデーターの両方を介してレコードを実行し、レコードの有効性を比較できます。時間。
この種の力により、プラグインのフォールスルー オーバーライドを定義することもできます。私が取り組んでいるアプリは、実際には 30 以上の実装用にデプロイされた同じコードベースです。そのため、通常、次のように尋ねてプラグインを探します。
これにより、起動するデフォルトのプラグインのセットをバンドルできますが、その特定の実装が顧客固有のルールで上書きしない場合に限ります.
IOC は優れたテクノロジですが、実際には、具体的な実装ではなく、インターフェイスへのコーディングを容易にすることが目的のようです。ただし、これらの実装を交換することは、IOC でのプロジェクト シフトのようなイベントです。MEF では、インターフェイスと具体的な実装の柔軟性を利用して、多くの利用可能なオプションの中から実行時に決定します。
ネタバレで失礼します。私が言いたかったのは、MEF を不必要に複雑にする 2 つの欠陥があるということです。
それは属性ベースであり、なぜ物事がそのように機能するのかを理解するのに役立ちません。フレームワークの内部に隠された詳細にアクセスして、そこで何が起こっているのかを正確に確認する方法はありません。トレース ログを取得したり、解決メカニズムに接続したり、未解決の状況を手動で処理したりする方法はありません。
一部の部品が拒否される理由を突き止めるためのトラブルシューティング メカニズムはありません。失敗した部分を指摘しても、その部分が失敗した理由はわかりません。
だから私はそれに非常に失望しています。実際の問題に取り組むのではなく、いくつかのクラスをブートストラップしようとする風車との戦いに多くの時間を費やしました。何をいつ作成するかを完全に制御でき、VS デバッガーですべてをトレースできる場合、昔ながらの依存性注入手法に勝るものはないと確信しました。MEF を支持する誰かが、単純な DI ではなく MEF を選択する理由について、多くの正当な理由を提示してくれることを願っています。
MEF が完全に機能する IoC フレームワークになり得ることに同意します。実際、私は現在、拡張性と IoC の両方に MEF を使用するアプリケーションを作成しています。私はそれの一般的な部分を取り出して「フレームワーク」にし、人々がそれがどのように機能するかを見たい場合に備えて、 SoapBox Coreと呼ばれる独自のフレームワークとしてオープン ソース化しました。
特に、 MEF の動作を確認したい場合は、ホストがどのように機能するかを調べてください。