MEFとMAFの選択（System.AddIn）

Managed Extensibility Framework（MEF）とManaged AddIn Framework（MAF、別名System.AddIn）は、非常によく似たタスクを実行するようです。このスタックオーバーフローの質問によると、MEFはSystem.Addinの代替品ですか？、両方を同時に使用することもできます。

どちらを使用するかをいつ選択しますか？どのような状況で両方を一緒に使用することを選択しますか？

私はこれらのオプションを評価してきましたが、ここで私が結論に至りました。

MAFは真のアドオンフレームワークです。アドオンを完全に分離することができます。別のアプリドメイン内で実行することもできるため、アドオンがクラッシュした場合でも、アプリケーションは停止しません。それはまたあなたがそれらに与える契約以外のものに依存することからアドオンを切り離す非常に完全な方法を提供します。実際、メインアプリをアップグレードしている間、コントラクトアダプターをバージョン化して、古いアドオンとの下位互換性を提供できます。これは素晴らしいように聞こえますが、アプリドメインをまたぐために支払う必要のある高額が付属しています。あなたはこの価格をスピードで、そしてあなたがやり取りできるタイプの柔軟性で支払います。

MEFは依存関係の注入に似ており、発見可能性や...（これに空白を描画する）などの追加の利点があります。MAFの分離度はMEFにはありません。これらは、2つの異なるもののための2つの異なるフレームワークです。

ダニエルクが言ったことは良いことです。追加します：

System.Addinsに関するビデオを見ると、彼らは明らかに非常に大規模なプロジェクトについて話している。彼は、ホストアプリケーションを管理する1つのチーム、各アドインを管理する別のチーム、およびコントラクトとパイプラインを管理する3番目のチームについて話します。これに基づいて、System.Addinsは明らかに大規模なアプリケーション向けだと思います。SAPのようなERPシステムなどのアプリケーションを考えています（それほど大きくはないかもしれませんが、アイデアはわかります）。これらのビデオを見ると、System.Addinsを使用するための作業量が非常に多いことがわかります。システムにサードパーティのアドインをプログラミングしている会社がたくさんあり、死刑のもとでこれらのアドイン契約を破ることができない場合は、うまくいきます。

一方、MEFは、SharpDevelopのアドインスキーム、Eclipseプラグインアーキテクチャ、またはMono.Addinsとの類似点を共有しているようです。System.Addinsよりもはるかに理解しやすく、はるかに柔軟性があると思います。あなたが失うものは、MEFと一緒にすぐに使えるAppDomain分離または強力なバージョン管理コントラクトを取得しないことです。MEFの長所は、アプリケーション全体をパーツの構成として構築できるため、さまざまな顧客向けにさまざまな構成で製品を出荷でき、顧客が新しい機能を購入した場合は、その機能のパーツをインストールディレクトリにドロップするだけです。そして、アプリケーションはそれを見て実行します。また、テストを容易にします。テストするオブジェクトをインスタンス化して、すべての依存関係のモックオブジェクトにフィードできます。

私が言及したい最も重要な点は、System.Addinsがすでにフレームワーク内にあるにもかかわらず、それを使用している人々の多くの証拠を見ていませんが、MEFはそこに含まれていると思われるCodePlexに座っているだけです.NET 4、そして人々はすでにそれを使って多くのアプリケーションを構築し始めています（私も含まれています）。これは、2つのフレームワークについて何かを教えてくれると思います。

MAFアプリケーションを開発して出荷した。MAFに対する私の見方はややぎこちないものです。

MAFは、最悪の場合、「分離」システムまたは「疎結合」システムです。MEFは、せいぜい「結合」システムまたは「疎結合」システムです。

MAFを使用して実現したMAFの利点は次のとおりです。

1. アプリケーションの実行中に新しいコンポーネントをインストールするか、既存のコンポーネントを更新します。アドインはアプリケーションの実行中に更新でき、更新はユーザーにシームレスに表示されます。そのためにはAppDomainが必要です。

2. 購入したコンポーネントに基づくライセンス。ユーザーの役割とアクセス許可によって読み込まれるアドイン、およびアドインの使用が許可されているかどうかを制御できます。

3. 迅速な開発（市場投入までの時間の短縮）。AddInの開発はアジャイル手法に完全に適合し、開発チームは一度に1つのAddInを開発しました。アプリケーションの他の部分との統合部分も開発する必要はありません。

4. 改善されたQA（一度に1つのコンポーネントのみのQA）。次に、QAは、機能の単一ビットの欠陥をテストして発行できます。テストケースの開発と実装が簡単になりました。

5. 展開（コンポーネントが開発およびリリースされ、「そのまま機能する」ようにコンポーネントを追加します）。展開は、アドインを作成してファイルをインストールするだけです。他の考慮事項は必要ありませんでした！

6. 新しいコンポーネントは古いコンポーネントと連動しました。初期に開発されたAddInは作業を続けました。新しいアドインはアプリケーションにシームレスに適合します

私の見解では、2つのテクノロジーは実際には非常に異なるユースケースを対象としています。

MEFは通常、最終的な統合ソリューションを提供する人またはグループがすべてを組み立て、全体的な整合性を保証するが、主要な機能のさまざまな実装を必要とする純粋な依存関係注入シナリオに最適です。

MAFは、誰か/グループがプラットフォームまたはホストを開発しており、他のグループが事実の後でホストグループの制御下にない方法で機能を追加するシナリオ用です。このシナリオでは、不正なアドインからホストを「保護」する（またはアドインを相互に保護する）より複雑なメカニズムが必要です。

3番目の類似パターンテクノロジは、ProviderBaseスキーム全体です。これにより、機能の置き換えも可能になりますが、その目標は、実際にはホスト/アプリが機能を絶対に必要とし、実際に構成を介してさまざまな実装を指定するシナリオです。

MAFとMEFの両方について説明しているこの長い記事を見つけました。 http://emcpadden.wordpress.com/2008/12/07/managed-extensibility-framework-and-others/

他の回答によるポイントに加えて、MEFとMAFの主な違いの1つは、Managed Extensibility Frameworkによって1つの構成可能な部分が別の部分に依存できるようになることです。たとえば、プラグインを別のプラグインに依存させることができます。

また、Managed Extensibility Frameworkは、System.AddInとは異なり、ホストとアドインを実際に区別しません。MEFに関する限り、それらはすべて単なる合成可能な部品です。

私の意見では、違いを発見する最良の方法は、いくつかの実践的なコードです。私は2つのMSDNウォークスルーを見つけました。どちらにも電卓の例があり、それらの実装を簡単に比較できます。

MEF： 単純な計算例使用MEF部品
（Mは anaged E xtensibility F ramework）

• MEFテクノロジを使用して簡単な計算機を構築する方法を示します。外部DLLをロードする方法は示していません。（しかし、あなたは単に使用することで例を修正することができます catalog.Catalogs.Add(new DirectoryCatalog("Plugins", "*.dll"));catalog.Catalogs.Add(new AssemblyCatalog(typeof(Program).Assembly));、計算機コード を使用して抽出する代わりに、を DLLプロジェクトを個別に契約することができます。）

• MEF は特定のディレクトリ構造を持つ必要はありません。小規模なプロジェクトであっても、簡単で簡単に使用できます。これは属性を処理して、何をエクスポートするかを宣言します。これは読みやすく理解しやすいものです。例： [Export(typeof(IOperation))] [ExportMetadata("Symbol", '+')] class Add: IOperation { public int Operate(int left, int right) { return left + right; } }

• MEFは自動的にバージョン管理を行いません

MAF： V1とV2バージョンのシンプルな計算MAFプラグイン
（Mは anaged Aを DDIN Fの ramework）

• V1プラグインを使用して計算機を構築する方法と、下位互換性を維持しながらV2プラグインに移行する方法を示します（注：プラグインのV2バージョンはここにあります。元の記事のリンクは壊れています）
• MAFは強制特定のディレクトリ構造を、そしてそれが故に、私は小さなプロジェクトのためにそれをお勧めしません、それを動作させるために定型コードの多くを必要とします。 例：

  Pipeline
    AddIns
      CalcV1
      CalcV2
    AddInSideAdapters
    AddInViews
    Contracts
    HostSideAdapters

MEFとMAFの両方が.NET Framework 4.xに含まれています。2つの例を比較すると、MAFプラグインはMEFフレームワークに比べてはるかに複雑であることがわかります。そのため、これらのフレームワークのどちらを使用するかを慎重に検討する必要があります。

MAFとMEFはどちらもAppDomainを使用でき、実行時にdllをロード/アンロードできます。ただし、私が見つけた違いは次のとおりです。MAFアドインは分離され、MEFコンポーネントは疎結合です。MEFはデフォルトでインスタンスを作成しますが、MAFは「アクティブ化」します（新しいインスタンス）。

MEFでは、Genericsを使用して任意の契約のGenericHostを作成できます。これは、MEFのロード/アンロードとコンポーネント管理が共通のライブラリにあり、一般的に使用できることを意味します。