プラグインのアーキテクチャにおけるリフレクションと属性

Question

私はサブディレクトリから起動時にプラグインをロードするアプリケーションに取り組んでいますが、現在はリフレクションを使って各アセンブリのタイプを繰り返し処理し、IPluginModuleインタフェース。

Reflectionにはパフォーマンスヒットが含まれていますし、しばらくしてからいくつかのプラグインがあると思いますので、アセンブリレベルで適用されたカスタム属性を定義すると便利でしょうか。タイプ（おそらく、IPluginModuleの1つの実装者を含むアセンブリ内の約12種類のタイプ）。

属性が存在する場合、必要な型またはインスタンスを返すメソッドを提供することができ、その型を反復処理するのはフォールバックのメカニズムにすぎません。タイプ情報を設定ファイルに格納することはオプションではありません。

パフォーマンスが向上しますか、実際にアセンブリからストレージをロードするのにかかる時間に比べて問題はありませんか？また、この使用法は属性にはまったく適していますか？

Answer 1

私は質問であなたの質問に答えます：なぜこれについて心配ですか？ が後日、いくつかのプラグインがあるかもしれないので

あなたは1時間の操作で可能性パフォーマンスヒットを心配しています。

アプリケーションの起動時間がユーザにとって長すぎる場合を除いて、私はそれについて考えるのに時間を浪費することはありません。アプリケーションを改善するためにはるかに優れた方法があります。

Answer 2

アトリビュートでタグ付けされたすべてのクラスをアセンブリに要求するとリフレクションも使用されると思っていました。次に、メタデータ、インターフェイス実装、または属性マーキングの検索が高速になりますか？

Answer 3

また、すべてのクラスをループするのではなく、正確なクラスを知るように、プラグ可能なタイプを構成に含めることもできます。このオプションにはいくつかの設定ユーティリティが必要ですが、ループするクラスの数に応じてパフォーマンスが向上する可能性があります。

Answer 4

Microsoftの2つの.netプラグインフレームワークであるManaged AddIn Framework（MAF）とManaged Extensibility Framework（MEF）はどちらも、属性やリフレクションを使用してプラグインを検出できます。だからMicrosoftは属性が適切だと感じているようだ。

ただし、パフォーマンスの違いはわかりません。

Answer 5

良い解決策は、プラグインに関するすべての情報をキャッシュすることです。アプリケーションが初めて起動されると、プラグインDLLのフルスキャンが実行され、ファイル内のタイプのリストが保存されます。次回アプリケーションが起動すると、ファイルから情報をロードします。これは、すべてのdllを再度スキャンするよりもはるかに高速です。アプリケーションは、各dllのタイムスタンプも保存することができるので、dllの変更を検出した場合は、dllを再スキャンしてキャッシュを更新することができます。

これは、基本的には、Mono.Addins frameworkが続く方法です。