MEFとMAFの選択（System.AddIn）

StackOverflow https://stackoverflow.com/questions/835182

質問

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

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

役に立ちましたか？

解決

これらのオプションを評価してきましたが、ここに私が思いついた結論があります。

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

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

他のヒント

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

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

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

私が言及したい最も重要な点は、System.Addinsが既にフレームワークにあるにもかかわらず、それを使用している人々の多くの証拠は見られないことですが、MEFは.NET 4に含まれるようになり、人々は既にそれを使用して多くのアプリケーションを構築し始めています（自分自身も含まれています）これで、2つのフレームワークについて何かお伝えできたと思います。

MAFアプリケーションを開発および出荷した。 MAFに対する私の見解はややうんざりしています。

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

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

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

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

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

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

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

  6. 新しいコンポーネントは古いコンポーネントで機能しました。早期に開発されたアドインは、引き続き機能します。新しいアドインはアプリケーションにシームレスに適合します

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

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

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

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

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に関する限り、これらはすべて構成可能なパーツです。

私の意見では、違いを見つける最良の方法は、実践的なコードです。 MSDNの2つのチュートリアルを見つけました。どちらも計算機の例で、実装を簡単に比較できます。

MEF： MEFパーツ を使用した簡単な電卓の例
（ M 変更済み E 拡張性 F ラムワーク）

  • MEFテクノロジーを使用して簡単な電卓を作成する方法を示します。外部dllをロードする方法は示しません。 （ただし、次のコマンドを使用して、簡単に例を変更できます。 catalog.Catalogs.Add（new DirectoryCatalog（＆quot; Plugins＆quot ;,＆quot; *。dll＆quot;））; catalog.Catalogs.Add（newを使用する代わりに AssemblyCatalog（typeof（Program）.Assembly））; を抽出し、 DLLプロジェクトを分離するための計算コードと契約。）

  • MEFは特定のディレクトリ構造を持つ必要はありません。小規模なプロジェクトでも簡単かつ簡単に使用できます。これは、属性と連携して、エクスポートされるものを宣言します。これは読みやすく、理解しやすいものです。 例： <コード> [エクスポート（typeof（IOperation））] [ExportMetadata（＆quot; Symbol＆quot ;, '+'）] クラス追加：IOperation {     public int Operate（int left、int right）     {         左+右に戻ります。     } }

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

MAF： V1およびV2バージョン MAFプラグイン を備えたシンプルな電卓
（ M 古い A ddin F ラムワーク）

  • V1プラグインを使用して電卓を構築する方法と、下位互換性を維持しながらV2プラグインに移行する方法を示します（注：プラグインのV2バージョンを見つけることができます< a href = "https://msdn.microsoft.com/en-us/library/vstudio/bb384194(v=vs.100).aspx" rel = "noreferrer">こちら、元のリンク記事が壊れています）
  • MAFは特定のディレクトリ構造を強制します。それを機能させるには多くの定型コードが必要なので、小規模なプロジェクトにはお勧めしません。 例： 
    Pipeline
  AddIns
    CalcV1
    CalcV2
  AddInSideAdapters
  AddInViews
  Contracts
  HostSideAdapters

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

MAFとMEFはどちらもAppDomainを使用でき、両方ともランタイムでdllをロード/アンロードできます。しかし、私が見つけた違いは次のとおりです。MAFアドインは分離され、MEFコンポーネントは疎結合です。 MAF＆quot; Activates＆quot; （新しいインスタンス）MEFはデフォルトでインスタンスを作成します。

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

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top