プロジェクトを編成するとき、MEFで使用されるプロバイダーインターフェイスをどこに配置する必要がありますか？現在、私は他のすべてと同じプロジェクトにそれらを持っていますが、それが非常に小さなdllであり、拡張機能を書き込もうとしている他の人によって簡単にリンクされるように、それらを別のdllに抽出することが望ましいようです。これの良い習慣は何ですか？
1142 次
4 に答える
6
他のプラグイン/拡張モデルと同様に、「コントラクト」（プラグインの作成者が実装する必要のあるインターフェイス）をアプリケーションとは別のアセンブリに配置する必要があります。
そうすれば、プラグインの作成者がアプリケーション全体を提供しなくても、そのアセンブリを利用できるようにすることができます。これは、個別にライセンスを取得する必要がある商用アプリの場合に便利です。
MEF Preview 5には、インターフェイスをエクスポートする機能（つまり、[Export]属性をインターフェイスに追加する機能）が導入されており、そのインターフェイスの実装者は自動的にエクスポートされます。つまり、プラグインの作成者はMEFについて知る必要さえありません。つまり、プラグインの作成者はインターフェイスを実装するだけで、自動的にMEF拡張機能になります。
于 2009-04-28T01:43:12.213 に答える
2
実際、.NET 4.0 には、これを実現できる型等価性と呼ばれる新機能があります。この機能を使用すると、異なるコントラクト アセンブリに 2 つの異なるインターフェイスを持たせて、それらが同じであることを CLR に伝えることができます。低レベルなので、MEF は問題なく動作します。
いくつかの注意事項:
- フレームワークの種類以外では、カスタム インターフェイスのみがサポートされています。
- カスタム ジェネリック インターフェイスはサポートされていません。
- マッチングには、両方のインターフェースで GUID が必要です :-(
詳細については、http: //msdn.microsoft.com/en-us/library/dd997297 (VS.100).aspx を参照してください。ドキュメントには COM 用と書かれていますが、マネージ コードにも使用できます。
于 2009-12-22T18:28:32.977 に答える
1
当初、MEF はダック タイピングを実装する予定でした。つまり、共通のアセンブリは必要ありませんが、どうやらこれは難しすぎることがわかりました。
インターフェイスの実装を支援するために使用できるいくつかの便利な抽象基本クラスと共に、それらすべてを共通のアセンブリに入れています。
于 2009-05-15T01:28:18.570 に答える
0
私も同じ質問をしていて、コントラクトが 1 つのプロジェクトで定義されている例、複数の実装が他のプロジェクトで定義されている例、およびコントラクトを使用し、実装 dll を簡単にコピーして利用できる拡張フォルダーを持つ別のコンシューマ プロジェクトを見たいと思っていました。コードを変更せずにコンシューマ アプリケーションを作成します。そこで、簡単な Hello World 系のアプリケーションを書いてみて、ブログに投稿しました。お役に立てば幸いです。ソース コード (C#) も投稿しました。
http://ppsinfo.blogspot.com/2009/11/managed-extensibility-framework-mef.html
于 2009-12-09T08:35:08.193 に答える