6

プラグインの読み込みの問題が解決したら (MEF を介した .NET の場合)、解決する次のステップはプラグインとの通信です。簡単な方法は、インターフェースを実装してプラグイン実装を使用することですが、プラグインはアプリケーションの動作方法を拡張するだけでよく、多くの拡張ポイントが存在する場合があります。

私の質問は、その拡張ポイントをどのように処理するかについてです。私はそれを行うさまざまな方法を見てきましたが、それぞれの長所と短所、およびこれを達成するためのより良い方法があるかどうかはわかりません。

  • イベント: 「拡張可能」にしたいすべてのものに静的イベントを追加します。たとえば、User クラスのカスタム検証を追加したい場合、OnValidation 静的イベント ハンドラーを追加し、プラグインの構築時にイベントを追加できます。
  • メッセージング: バスとメッセージを持つこと。プラグインは特定のメッセージをサブスクライブし、他のクラスがそのメッセージを発行したときに何かを行うことができます。メッセージには、プラグインが機能するコンテキストが含まれている必要があります。検証の場合、ロジック レイヤーは UserValidation メッセージを発行し、メッセージが受信されるとプラグインが動作します。
  • インターフェース: ホスト アプリケーションは、特定のインターフェースを実装するすべてのプラグインを呼び出して、現在の操作のコンテキストを提供する責任があります。検証の場合、プラグインは Validate(object context) メソッドを使用して IValidator または IUserValidator を実装できます。

公開されたアプローチのいずれかを使用したことがありますか? どれがあなたにとって最も効果的でしたか?

ご質問の前に、私たちのアプリケーションは、その上にクライアント固有のコンテンツ中心の Web アプリケーションを構築するための拡張可能なコア (ユーザー、ローラ、およびコンテンツ管理) です。すべてが ASP.NET MVC 上に構築されています。

4

2 に答える 2

2

設計上の決定の鍵は、プラグインが互いにどのように異なるかを分析して明確に把握することです.

たとえば、静的イベントを扱う場合、おそらく各イベントを何らかの形式のトークン、列挙型、オブジェクトなどとして定義する必要があります。プラグインごとに新しいイベント セットを定義しなければならないことは、特に疎結合に関して、設計全体に自然に影響します。そして再利用します。

プラグインが非常に異なる場合は、バス/メッセージング アーキテクチャを使用することでメリットが得られる可能性があります。そのような場合、プラグインがサブスクライブできる通信交換のドメイン/カテゴリを導入できるからです。つまり、一連のイベントとメッセージが特定の関心領域にある可能性があります。ここで、特定のカテゴリ内の通信は引き続き静的イベントを使用できることに注意してください。したがって、これら 2 つの選択肢は相互に排他的ではありません。

プラグインによって実装される直接インターフェースは、私の経験では、プラグイン アーキテクチャの最も厳密なアプローチです。プラグイン インターフェイスを拡張すると、通常、プラグインとプロバイダーの両方でコードが変更されます。アプリケーションがかなりの期間存続できることがわかっている、しっかりした一般的なインターフェイスが必要です。

設計を 2 つの側面 (通信チャネルプロトコル) に分割することで、設計を処理しやすくなる場合があります。静的イベント処理はプロトコルの問題ですが、バス メッセージングとダイレクト インターフェイスはチャネルの問題です。

一般的に、プロトコルは最初から正しく設計するのが最も難しいと言えます。なぜなら、線を引くことができる一般的または具体的な方法について確かな感覚を持っていないからです。

編集: Lars は彼のコメントで重要な点を指摘しました - プラットフォームが例外をサポートしている場合、直接インターフェースを使用するときに多くのエラー処理を集中化でき、プラグインが一般的でおそらく特定のドメイン外のエラーを処理する必要がなくなります (例: 「プラグインの読み込みエラー」または「ファイルのオープンに失敗しました」)。ただし、プラグインを追加するたびにインターフェイスを維持する必要がある場合、そのような利点は薄れます。最悪のケースは、インターフェースが最初から何をサポートすべきかを認識していなかったために、途中でインターフェースに一貫性がなくなり始めた場合です。かなりの量のプラグインがすでに考案されている場合、インターフェース設計全体をリファクタリングするのは簡単な作業ではありません。

于 2009-11-18T12:39:30.330 に答える
0

オブザーバーパターンを使用します。GOF より:

オブジェクト間の 1 対多の依存関係を定義して、1 つのオブジェクトの状態が変化したときに、そのすべての依存関係が通知され、自動的に更新されるようにします。

パブリッシュ-サブスクライブとも呼ばれ、例のケース 2 と最もよく一致することをお勧めします。

于 2009-11-18T12:44:31.697 に答える