4

MVVM 設計に実装されている Event Aggregator パターンについて読みましたが、ViewModel 間の通信を分離するのに役立ちます。

Event Aggregator は本当に良いアイデアだと思いました。しかし、よく考えてみると、Event Aggregator は ViewModel によってのみ使用されるのでしょうか? モデルは Event Aggregator のイベントに対して発行および購読できますか?

これにより、おそらく ViewModel と Model の間のデータ変更を EventAggregator を介して関連付けることができます。これにより、ViewModel がすべてのモデルへの参照を格納することなく、1 つの ViewModel が複数のモデルから情報を取得できる可能性があります。

これを行うと、アーキテクチャ全体が乱雑になり、最終的にアンチパターンになりますか? ベストプラクティスは何ですか？

編集：

なぜ私がこれを求めているのかについて少し説明する必要があると思いました。次の 3 つの問題が考えられます。

まず、DI を使用すると、ViewModel がモデルをラップします。その後、ViewModel はモデルと通信できます。ただし、その逆ではありません。したがって、モデル自体または外部で何らかの変更があった場合、ViewModel に通知する方法が必要です。

次に、ViewModel が他の ViewModel と通信する必要があることは別として、モデルは ViewModel と同じかそれ以上に他のモデルと通信する必要があるように思えます。これらは、すべてを EventAggregator にリンクさせることができると私が考えていたことにつながります。

3つ目は、単一の ViewModel が複数のモデルから情報を取得する必要がある場合があることです。ただし、ViewModel のコンストラクターを介した依存性注入により、1 つのモデルからしか読み取ることができません。

4

1 に答える 1

8

イベント アグリゲータを使用する場所がいくつかあります。

  1. ビューモデル レベルで、ビューモデルが、関心のある他のオブジェクトが受信できる通知を送信したり、関心のあるイベントに関するメッセージを受信したりできるようにします。
  2. モデルがデータのストリームを送信しているサービス (ま​​たはモデル) レベル。メソッド呼び出しを介してデータを要求するビューモデルの代わりに、単に「新しいデータ」イベントを受け取ります。
  3. ビューモデルに同じデータを提供する複数のサービスがある場合、データを単一のストリームに集約できます。
  4. ビューモデルやサービスに、正常に終了する必要があることを知らせるシステム全体のイベント (システム シャットダウン) があります。これにより、シャットダウンする時間が与えられます。

イベント アグリゲーターの使用には欠点があることに注意してください。

  1. レベルまたは間接性が追加され、コードが読みにくくなります。イベント パブリッシャーとサブスクライバーのマッピングは、使用している開発ツールによっては面倒な場合があります。
  2. それを機能させるには、大量の「足場」コードが必要です。これは、使いすぎると負担になる可能性があります (どのイベントが何をするかなどを追跡する必要があります)。
  3. 単純なデータ要求の場合、サービス メソッドをイベント アグリゲーター イベントに置き換えることは、ほとんどの場合うまくいきません。メソッド呼び出しごとに 2 つのイベント (要求イベントと応答イベント) が必要です。また、間違ったビューモデル データを送信することにも注意する必要があります。ビューモデル A がデータのリクエストを送信し、その応答がビューモデル A と B によって受信された場合、ビューモデル B が応答を除外できるようにする必要があります。

通常、私はサービス間通信を提供するためにイベント アグリゲーターを使用しません (私の主な作業プロジェクトでは 20 のイベントがあり、そのうちの 1 つだけがサービス間通信です)。これは、私のサービス呼び出しのほとんどがデータに対する単純な 1 回限りの要求であり、更新の継続的なストリームではないためです。

于 2012-10-26T10:18:24.483 に答える