2

プラグイン モジュールを介してカスタマイズをサポートする必要があるシステムを開発しています。システムにプラグインできるようにするために、プラグインコードがこれらのインターフェースを実装するだけでよいように、インターフェースに対してコーディングしています。

// for illustration purposes; not actual code
public interface IPluggable
{
    void Setup(PluginConfig c);
    bool Process(IProcessable p);
}

アセンブリ名と完全修飾型名が指定されている、ロードする必要があるプラグインを構成から読み取ります。

<plugin assembly="Foo.Bar.PluginAssembly" type="Foo.Bar.Plugins.AwesomePlugin" />

型がFoo.Bar.Plugins.AwesomePlugin実装さIPluggableれ、アセンブリに含まれる場所Foo.Bar.PluginAssembly.dll。この情報を使用して、必要なプラグインのインスタンスを作成します。

IPluggable plugin = (IPluggable)Activator.CreateInstance(assemblyName, typeName).Unwrap();

だから私の質問は3つあります：

  1. プラグイン システムの推奨パターンは何ですか? 私が取っているアプローチは理にかなっていますか、それとも私が見逃している明らかな欠陥/警告はありますか?
  2. Activator.CreateInstance()プラグイン オブジェクトを動的にインスタンス化するための適切な選択はありますか?
  3. 読み込むアセンブリとその場所をより具体的にするにはどうすればよいですか? .\pluginsたとえば、サブフォルダーにあるアセンブリからのみプラグインを読み込みたいとします。
4

1 に答える 1

4

質問への回答は次のとおりです。

  1. 私はこれが好きで、プラグイン コンポーネントを作成する必要があるときに、このようなパターンを使用します。さまざまなフレームワークの使用を推奨する人もいます。MEFが非常に人気があることは知っています。しかし、.NET フレームワークを使用することは私にとって十分に簡単であり、MEF フレームワークを学習することは、学習して覚えておく必要があるもう 1 つのことです。おそらく試してみる価値はありますが、あなた次第です。

  2. 私はいつも を使用してきましAssembly.CreateInstanceたが、その違いはおそらくあなたに影響を与えることはないでしょう ( Assembly.CreateInstance と Activator.CreateInstance の違いは? )

  3. System.IO名前空間を使用するだけです。このDirectoryInfoクラスには、特定のパターン (おそらく*.dll) に一致するすべてのファイルを列挙するメソッドがあります。一致するたびに、System.Reflection名前空間を使用して、インターフェイスを実装する型を調べて見つけますCreateInstance。

MEF についての私の意見は次のとおりです。多数のシステムまたはプロジェクトで大規模で管理しやすく柔軟なプラグイン システムを使用する場合は、他の人が行っている作業を活用して、それに非常に興味があります。時間を節約し、よくある落とし穴を避けるために行われます。

非常に単純な 1 回限りのプラグイン システムを作成していて、.NET フレームワークを使用してそれを行う方法の基本を知っている場合、MEF を学習するオーバーヘッドをスキップしてコードを作成します。妥当なプラグイン プロセスを 1 時間もかからずに作成できましたが、MEF をダウンロードし、参照し、構成しようとした後では、それについて何かを示すことはできないと思います。

于 2013-03-14T20:52:43.313 に答える