MEFと任意のIoC
MicrosoftのManagedExtensibility 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製品1からORM製品2に基づくIUserRepositoryを交換できるようにすることを目的としています。ただし、ほとんどのIOCソリューションは、特定の時間に有効なIUserRepositoryが1つだけであることを前提としています。
ただし、特定のページリクエストの入力データに基づいて選択する必要がある場合、通常、IOCコンテナは途方に暮れます。
例として、私がしばらく取り組んできた大きなWebアプリのMEFプラグインを介して、権限チェックと検証を行います。 MEFを使用すると、レコードのCreatedOn日付を確認し、レコードが作成されたときに実際に有効であった検証プラグインを探して、そのプラグインと現在有効なバリデーターの両方でレコードを実行し、レコードの有効性を比較できます。時間。
この種の機能により、プラグインのフォールスルーオーバーライドを定義することもできます。私が取り組んでいるアプリは、実際には30以上の実装にデプロイされたものと同じコードベースです。したがって、私たちは通常、次のことを求めてプラグインを探しに行きます。
- 現在のサイトと問題の特定のレコードタイプに固有のインターフェイスの実装。
- 現在のサイトに固有のインターフェイス実装ですが、あらゆる種類のレコードで機能します。
- あらゆるサイトとあらゆるレコードで機能するインターフェース。
これにより、起動するデフォルトのプラグインのセットをバンドルできますが、その特定の実装が顧客固有のルールでオーバーライドしない場合に限ります。
IOCは優れたテクノロジですが、実際には、具体的な実装ではなく、インターフェイスへのコーディングを容易にすることを目的としているようです。ただし、これらの実装を交換することは、IOCにおけるプロジェクトシフトのようなイベントです。 MEFでは、インターフェイスと具体的な実装の柔軟性を利用して、多くの利用可能なオプション間で実行時の決定を行います。
話題から外れたことをお詫び申し上げます。 MEFを不必要に複雑にする2つの欠陥があると言いたかっただけです。
それは属性ベースであり、物事がそのように機能する理由を理解するのに何の役にも立ちません。フレームワークの内部に隠されている詳細にアクセスして、そこで何が起こっているのかを正確に確認する方法はありません。トレースログを取得したり、解決メカニズムに接続して、未解決の状況を手動で処理したりする方法はありません。
一部の部品が拒否される理由を解明するためのトラブルシューティングメカニズムはありません。失敗した部分を指しているにもかかわらず、その部分が失敗した理由はわかりません。
とてもがっかりしました。 bootstrap実際の問題に取り組む代わりにいくつかのクラスを試そうとする風車との戦いに多くの時間を費やしました。何がいつ作成され、VSデバッガーで何でもトレースできるので、MEFを提唱する誰かが、プレーンDIよりもMEFを選択する理由について多くの正当な理由を提示してほしいと思います。
MEFは完全に機能するIoCフレームワークになる可能性があることに同意します。実際、私は現在、拡張性とIoCの両方にMEFを使用することに基づいてアプリケーションを作成しています。私はそれの一般的な部分を取り、それを「フレームワーク」にして、人々がそれがどのように機能するかを見たい場合に備えて、 SoapBox Core と呼ばれる独自のフレームワークとしてオープンソース化しました。
特に、MEFの動作を確認したい場合は、 Host がどのように機能するかを確認してください。