問題タブ [mef]

簡単な背景:

私のチームは、システムに新しい「プロバイダー」を追加するための拡張可能なモデルを提供するために、Microsoft の Managed Extensibility Framework ( MEF ) を使用することにしました。

これにより、新しいサードパーティ プロバイダーを比較的簡単にプラグインできます。

注: MEF を簡単に使用して起動して実行できることに感銘を受けました。

私の質問：

これらのプロバイダーには一般に異なるプロパティが関連付けられているため、実行時にこれらのプロバイダーをシステムにロードするときに、プロバイダーのデータ ストリームとプロパティにアクセスする必要があります。

プロパティが異なるため、上記のプロバイダー プラグインを操作するには、どのようなアプローチを取る必要がありますか? それらはすべて同様の仕事をしていることに注意してください。

私の解決策：

プロバイダーが準拠する必要があるインターフェイスを作成します。これにより、各サードパーティ プロバイダーの周りに「ラッパー」が作成され、各プロバイダーと連携するための一貫したインターフェイス/プログラミング モデルが得られます。

プラグイン = サード パーティのデータ ソース (プロバイダー) + 共通インターフェイスの実装。

+ve: 上記のプラグインには、より複雑なリフレクション ベースのダイナミックな「プラグ」は必要ありません。

-ve: プロバイダーごとにラッパーを作成する必要があります。(関係なく、MEF Export タグを追加する必要があります)

さらに注意:

私にとっては、インターフェイス/ラッパーのアプローチが最も単純ですが、システムに公開できるプロパティを実行時に発見するために、リフレクションを利用する可能性のあるリフレクション ベースのアプローチを調査するように言われました。

私は特定の解決策に賛成しているわけではありませんが、コミュニティの考えを聞くことに興味があります (そのほとんどは私よりも経験豊富です)。

ありがとう。

Microsoft の Managed Extensibility Framework (MEF) とさまざまな IoC コンテナー (Unity など) を見ると、あるタイプのソリューションを別のタイプのソリューションよりも優先して使用するタイミングがわかりません。より具体的には、MEF はほとんどの IoC タイプ パターンを処理し、Unity のような IoC コンテナーは必要ないように思われます。

理想的には、MEF の代わりに、または MEF に加えて、IoC コンテナーが使用される適切なユース ケースを見たいと考えています。

ビジネス ロジック用のモデル アセンブリ (Model クラスを含む) を使用する asp.net アプリケーションがあります。このモデル アセンブリは、IMailService インターフェイスを介して MailService に依存しており、MEF を使用して MailService 実装のモデルのニーズを満たすことを試みています。Model クラスのコンストラクターで MEF 合成を行っています。

この背後にあるアイデアは、サイト自体がメールの送信方法を知る必要なく、Web サイト間で再利用できる MailService アセンブリを作成することです。IoC コンテナーの方が適しているかもしれませんが、MEF アプローチの方が理解しやすく、パーツを組み合わせてアプリを構成するというアイデアが気に入っています。また、IoC コンテナーと比較した場合、mef アプローチにはマイナス面がありますか?

以下のコードは別のアセンブリにあり、インターフェイスはさらに別のアセンブリにあります

これは、モデル アセンブリの単体テストでは問題なく動作しますが、asp.net サイトからモデル アセンブリを使用すると、以下の例外で失敗します。また、web.configで信頼を完全に設定しようとしましたが、まだ運がありません

構成は相変わらず。次のエラーのため、変更は拒否されました: 構成で 1 つの構成エラーが発生しました。根本的な原因を以下に示します。詳細については、CompositionException.Errors プロパティを確認してください。

1) 制約に一致するエクスポートが見つかりませんでした"ExportTypeIdentity"))))'.

結果: Model.Model' の一部に import Model.Model._mailService (ContractName="ExtensionInterfaces.IMailService")' を設定できません。要素: Model.Model._mailService (ContractName="ExtensionInterfaces.IMailService") --> Model.Model

MEFはPRISMの代わりになりますか？

現在、アプリケーションに拡張性を追加する手段を提供する必要があります。私は現在、MEFとMAFを見ています。

MEF は、より単純なプログラミング モデルを提供し、単一の AppDomain にのみアドインをロードする必要があるため、使用シナリオにより適しています。これは、システムの設計方法によるものです。MAF を使用しても、数行のコードで同じことが実現できます。

しかし、MEF がプレビュー ステータスであることを考えると、本番システムで使用する必要があるかどうか疑問に思っていました。

私のすべての「パーツ」は、この IPlugin インターフェイスを実装しています。私の部品には明らかに輸入/輸出要件/提供物があります。

私は、ユーザーが必要なものを動的に選択するビルド + 構成システムを作成しています。これは、呼び出されるプラグインのセットに変換されます。

たとえば、プラグインのリストは次のとおりです。

(1) X をインストール ... "XTypeInstalled" をエクスポート

(2) X の構成 ... "XTypeInstalled" をインポートし、"XTypeConfigured" をエクスポートします。

(3) Y をインストール ... "XTypeConfigured" をインポート

(4) Zのインストール

(5) 設定A

ここで、ユーザーは (1)、(3)、および (4) を選択することも、(1)、(2)、(3) を選択することもできます。

私が直面している問題は、すべてのプラグイン作成者が IPartImportsSatisfiedNotification を実装する必要があるかどうかです。そうでない場合、ユーザーは (1)、(2)、(3) のワークフローを選択します ... (3) の execute() メソッドを呼び出すにはどうすればよいですか。

私は理にかなっていますか？

最終的な目標は、コントロールをプラグインとしてロードして、AvalonDock で DocumentContent として使用することです。結果として、これらのコントロールの複数のインスタンスを作成できるようにする必要があり、プラグイン作成者のオーバーヘッドをできるだけ制限して作成したいと考えています。

私の最初の意図は、プラグインを見つけて管理するために MEF を使用することでしたが、この質問は、少なくとも現時点では、MEF がこれを意図していない可能性があることを暗示しているようです。

別のソリューションを使用する必要がありますか (DI コンテナーのドメイン、または具体的には MEFは、クラスのインスタンスを提供することに限定されていると見なされ、問題により適切に対応する別のソリューションはありますか)、または提案されたソリューションを使用する必要があります (使用するなど)。インスタンスを複製するためのリフレクション、またはプラグインの作成者にファクトリ メソッド/オブジェクトを提供することを要求する - 一見ハックっぽい) MEF を操作する (または、これを達成するために MEF を構成する簡単な方法はありますか)?

WPF アプリケーションに Managed Extensibility Framework を使用しています。アプリケーションに新しい機能を提供する、いわゆる拡張ポイントのインターフェースを定義しました。

これらの機能の一部は、特定のデータ テンプレートを使用してデータを表示する場合があります。これは、おそらく xaml リソース ファイルで指定する必要があるものです。

アプリケーションのコンパイル時に認識されないアセンブリで定義されたこれらの拡張ポイント (つまり、プレーン言語のプラグイン) の 1 つがあり、それでもプラグインのリソースをアプリケーションのリソースとマージしたい場合、どうすればよいでしょうか?

パック URI 表記法を使用してこれを行う方法を示すすべての例は、参照するアセンブリがコンパイル時にわかっている場合の解決策です。コンパイル時のアセンブリに慣れていない場合、どうすれば同じことを達成できますか?

私は MEF を初めて使用し、それを使用してプラグイン システムを構築しようとしていますが、ステップ 1 で行き詰っています。

Andrew Whitechapelの記事をフォローしています。彼のサンプル コードをダウンロードしたところ、正常に実行されました ("エクスポート" アセンブリの 1 つを削除すると、それらは彼のサンプルでは相互に排他的であり、MEF アセンブリを参照します)。

このサンプルは、単一のパーツのインポートを示しています。複数のパーツをインポートしたい (すべて同じインターフェースに基づく)。そこで、サンプルコードを次のように変更します。

IEnumerable の System.Collections.Generic もインポートしました。

重要な変更は最初のものです。私が理解しているように、これにより、複数のアセンブリからパーツをインポートできるようになります。ただし、次のエラーが表示されます。

この時点では、複数の「プラグイン」アセンブリを追加していません。まだ持っているだけです。

完全を期すために、「プラグイン」クラス ライブラリ内の彼のエクスポート定義 (私は触れていません) を次に示します。

何か案は？ここで頭をかいてます。私は SO と MEF フォーラムを検索しましたが、私を啓発するものを見つけることができました。

VS 2008 SP1 (2010 ベータ版はインストールされていません) と最新の System.ComponentModel.Composition アセンブリ (2009.26.8.0) を使用しています。

タイトル失礼します、言葉が詰まってしまいました

MEFの池につま先を浸しています。ここまでは順調ですね。ホスト アプリと、エクスポートする "プラグイン" アセンブリがいくつかあります。ホスト アプリは、単純なプロパティDescriptionAttributeを継承して持つ属性を定義します。私のテストフォームには. これは MEF によって適切に埋められ、コレクションをめくることができます。プロパティは埋められ、人生は黄金色です。後で個別のアセンブリに分割しますが、現時点では概念実証にすぎません。ExportAttributeName<ImportMany> IEnumerable(Of Lazy(Of IDoStuff, IDescriptionAttribute))Name

さて、問題は次のとおりです。私が持っている属性を介して、IDoStuff実装しDescriptionAttributeている「プラグイン」クラスを身に着けているアセンブリバージョンを公開する方法はありますか? DescriptionAttributeこれまでのところ、属性のコンストラクターに渡す試みはすべて失敗しました。スタジオは、定数式が必要であると言い続けています (当然のことです)。IDoStuff インターフェイスを介して公開することもできますが、DescriptionAttribute代わりに属性の一部として使用する方がはるかに優れていて、"気分" が良くなります。ハードコードすることもできますが、「プラグイン」の新しいバージョンをリリースするときに更新するのを忘れる別の場所です:-)