まず、私のブログでこの問題の背景を少し紹介します。
- http://www.codebork.com/coding/2008/06/25/message-passing-a-plug-framework.html
- http://www.codebork.com/coding/2008/07/31/message-passing-2.html
説明があまり明確ではないことを認識しているので、ここでできる限りのことを要約しようと思います。アプリケーションは、個人的な財政プログラムです。フレームワーク自体の詳細については、この投稿の最後にあります。
フレームワークが処理できるプラグインにはさまざまな種類があります（アカウント、エクスポート、レポートなど）。ただし、問題を引き起こしているのはこのクラスであるため、特定のクラスのプラグイン、いわゆるデータプラグインに焦点を当てています。アカウント用、トランザクション用など、1つのクラスのデータプラグインがあります。
私は大規模なリファクタリングの途中で、データプラグイン用の次のアーキテクチャを残しました。
- データプラグインオブジェクト（初期化、インストール、およびプラグインメタデータの実装）[実装
IDataPlugin<FactoryType>] - データオブジェクト（アカウントなど）[実装、例
IAccount] - データオブジェクトのインスタンスを作成するファクトリ[実装、例
IAccountFactory]
以前は、データオブジェクトとプラグインオブジェクトが1つに統合されていましたが、これは、アカウントに記録されたトランザクションごとに新しいトランザクションプラグインをインスタンス化する必要があり、多くの問題を引き起こしていました。残念ながら、そのリファクタリングは私のメッセージパッシングを壊しました。データオブジェクトはを実装INotifyPropertyChangedしているので、新しい問題が発生しました。回避方法がわかりません。プラグインオブジェクトはメッセージブローカーにイベントを登録していますが、実際に発生するのはデータオブジェクトです。イベント。これは、サブスクライブプラグインが現在、作成された各アカウント、トランザクションなどにサブスクライブする必要があることを意味します。 これは明らかにスケーラブルではありません。
私が現時点で知る限り、私には2つの可能な解決策があります。
- データプラグインオブジェクトをデータオブジェクトとメッセージブローカーの仲介役にし、場合によっては変更通知をバッチ処理します。これがなくてもできるはずだと私が感じているメッセージングシステムに別の複雑さの層を追加するので、私はこれが好きではありません。
- 現在のイベントベースの実装をジャンクし、より簡単に管理できる他の何かを使用します（メモリ内のWCF ?!）。
だから私は本当に尋ねていると思います：
- この問題をどのように解決しますか？
- 私が見落としている可能性のある解決策は何だと思いますか？
- 私のアプローチは漠然と軌道に乗っている/賢明ですか？！:-)
ブログ投稿の日付からわかるように、この問題のいくつかの変種は、かなり長い間私に負担をかけてきました！そのため、すべての回答をいただければ幸いです。
フレームワーク自体の背景は次のとおりです。
私のプラグインフレームワークは、プラグインブローカー、設定マネージャー、メッセージブローカーの3つの主要コンポーネントで構成されています。プラグインブローカーは、プラグインの発見と作成という、プラグインの基本的な作業を行います。プリファレンスマネージャーは、フレームワークと個々のプラグインのユーザープリファレンスを管理します。たとえば、有効になっているプラグイン、データを保存する場所などです。通信はパブリッシュ/サブスクライブを介して行われ、メッセージブローカーが中央に配置され、すべてが収集されます。パブリッシュされたメッセージタイプとサブスクリプションの管理。パブリッシュ/サブスクライブは現在、.NETインターフェイスを介して実装されています。このインターフェイスは;
INotifyPropertyChangedと呼ばれる1つのイベントを提供します。PropertyChangedメッセージブローカーは、実装しているすべてのプラグインのリストを作成しますINotifyPropertyChangedこのイベントで他のプラグインをサブスクライブします。メッセージパッシングの目的は、アカウントプラグインとトランザクションプラグインがストレージプラグインにデータが変更されたことを通知して、データを保存できるようにすることです。