2

Aある意味でプラグインを使用するクラス（静的クラスではない）があるとしましょう。MEFを使用してこれらのプラグインを管理し、ユーザーがパーツカタログを追加するためのメソッドを追加します。使用例：

var myA = new A();
myA.LoadPlugins(new DirectoryCatalog("path/to/plugins"));
myA.DoStuffWithPlugins();

Aクラスと同じ名前空間B。Bまた、MEFを使用してプラグインを管理し、独自のを持っていCompositionContainerます。ユーザーがのプラグインを操作したい場合は、のプラグイン管理メソッドBを使用する必要があります。B

B上記のように使用されAます。

私の質問は、これは悪いですか？名前空間にプラグインをロードするための2つの別々の場所があることに注意する必要がありますか？それが悪い場合、代替案は何ですか？

4

2 に答える 2

2

私の質問は、これは悪いことですか? 名前空間にプラグインをロードする場所が 2 つあることに注意する必要がありますか? それが悪い場合、代替手段は何ですか？

必ずしも。同じアプリケーション内で 2 つの完全に別個のコンポジションを使用できない理由はありません。

そうは言っても、ほとんどの場合、複数のコンポジションを持つ本当の理由はありません。MEF は両方のデータ セットを一度に作成します。あなたの場合、インポーターとレポートを同じ構成コンテナーで構成できます。これにより、システムを拡張している誰かが、アプリケーションの両方の部分を拡張する単一のアセンブリのみを作成できるという利点があります。

ここで考えられるマイナーな危険信号の 1 つは、これらが同じ名前空間内の 2 つの別個のタイプであるが、それぞれに独自のプラグイン システムがあることです。通常、完全なプラグイン システムを備えたフレームワークは、それらが同じ名前空間に属しているかどうか疑問に思うほど複雑になります。不適切。

于 2012-06-16T01:34:09.617 に答える
1

私はそれで何の問題もありません。class Aメソッドを再利用するための基本クラスをお勧めしclass Bます。

class A : BaseCompositionClass {
    //    implementations
}

class B : BaseCompositionClass {

    //    implementations
}

単一のプロバイダーを使用CatalogExportProviderして、一致するインポートとエクスポートに対してそのプロバイダーを照会できます。その後、単一CompositionFactoryの which を使用して、コンポジションclassAをリクエストできます。classB

于 2012-06-16T01:32:13.597 に答える