11

私はCompositeApplicationLibraryを調べてきましたが、それは素晴らしいことですが、EventAggregatorをいつ使用するかを決めるのに苦労しています...というより、いつ使用しないかを決めるのに苦労しています。

StockTraderRIの例を見ると、私はさらに混乱しています。彼らは、ある場合にはEventAggregatorを使用し、他の場合には「クラシック」イベントを使用しています（たとえば、IAccountPositionServiceインターフェース）。

バックグラウンドスレッドで実行する必要がある重い作業タスクとの通信に使用することをすでに決定しました。この場合、EventAggregatorは舞台裏でスレッドのマーシャリングを提供するので、それについてあまり心配する必要はありません。それに加えて、このアプローチが提供するデカップリングが好きです。

だから私の質問は：私のアプリケーションでEventAggregatorを使い始めたら、すべてのカスタムイベントにそれを使ってみませんか？

4

1 に答える 1

21

これは良い質問です。Composite WPF (Prism) では、アプリのパーツ間で通信する方法が 3 つあります。1 つの方法は Commanding を使用することです。これは、UI によってトリガーされるアクションを、そのアクションを実装する実際のコードに渡すためだけに使用されます。もう 1 つの方法は、共有サービスを使用することです。この場合、複数の部分が同じサービス (シングルトン) への参照を保持し、そのサービスのさまざまなイベントを従来の方法で処理します。切断された非同期通信の場合、既に述べたように、最善の方法は Event Aggregator を使用することです (これは Martin Fowler のパターンに密接に従います)。

さて、それを使用する場合と使用しない場合:

  1. モジュール間で通信する必要がある場合に使用します。(たとえば、Task モジュールは、Task が他のモジュールによって作成されたときに通知される必要があります)。
  2. 同じイベントのレシーバーまたはソースが複数ある場合に使用します。たとえば、オブジェクトのリストがあり、そのタイプのオブジェクトが保存または作成されるたびにリストを更新したいとします。開いているすべての編集/作成画面への参照を保持する代わりに、この特定のイベントをサブスクライブするだけです。
  3. モデル ビュー プレゼンター領域で通常のイベントをサブスクライブするだけでよい場合は、使用しないでください。たとえば、プレゼンターがモデルの変更をリッスンし (たとえば、モデルが INotifyPropertyChanged を実装する)、プレゼンターがそのような変更に対応する必要がある場合は、プレゼンターがモデルの PropertyChanged イベントを直接処理することをお勧めします。イベントアグリゲーター。そのため、送信側と受信側の両方が同じユニットにある場合、そのようなイベントをアプリケーション全体に「ブロードキャスト」する必要はありません。

これがあなたの質問に答えることを願っています。

于 2009-02-18T06:35:29.417 に答える