2

基本的な「プラグイン可能な」アーキテクチャが必要であり、実装に関する私の仮定とアイデアが私が信じているとおりであるかどうかに興味がありました。一部の機能をサポートするすべてのクラスを含む「プラグインレジストリ」を設定するための基本的なプロセスは次のとおりです。

  1. アセンブリ内のクラスを熟考し、プラグイン基本クラスから継承しているクラスを見つけます。
  2. クラス名から名前を格納し、派生型への参照を取得し、属性から「プラグインタイプ」などのメタ情報を取得する可能性がある、新しい「ModulePlugin」オブジェクトを生成します。
  3. 上記のプラグインタイプは、リクエストに応じて派生タイプの新しいインスタンスを作成しますが、上記の「ModulePlugin」オブジェクトのプラグイン基本クラスとして返します。
  4. 生成されたプラグインをリストに保存します

ステップ4では、静的型初期化子を使用して静的クラス「PluginRegistry」を使用してこれを実行し、生成されたデータ構造（List <Plugin>）を静的読み取り専用IEnumerable<Plugin>に格納します。

アプリケーション全体で、プラグインを次のように使用します。

PluginRegistry.Plugins.Where(plugin => plugin.Type == Logger).Foo();

これはASP.NETMVCアプリケーションにあります。私は仮定しています：

  1. タイプ初期化子/コンストラクターは、同時アクセスが発生するこの方法で安全に使用できます（ASP.NET）
  2. 必要なリフレクションは、特定のアプリプールのライフサイクルに対して1回だけ実行され、より正確には、これは型の初期化を使用する静的クラスであるため、リクエストごとに何度も実行されることはありません。

試作品は機能していますが、不測の事態が心配です。

私の仮定は正しいですか、そして私が知っておくべき落とし穴はありますか？

4

0 に答える 0