3

パッシブビューでMVPを初めて実装しようとしていますが、このパターンで誰が誰に通知しているかについて少し混乱しています。ビューが変更された場合はビューがプレゼンターに通知し、次にプレゼンターが他のすべてのユーザー（他のビューとモデル）に通知することを理解しています。

今、私の場合、複数のビューがあり、UIの外部で変更できるモデルもあります。次の2つのシナリオが発生する可能性があります。

  1. View [i]が変更され、Presenterに通知されます。プレゼンターは他のすべてのビューとモデルに通知する必要がありますが、View[i]には通知しません。さらに、ビューもモデルも、変更されたばかりであっても、変更通知をプレゼンターに送信することはできません（そうしないと、イベントの無限ループが発生します）。

  2. モデルが変更され、プレゼンターに通知されます。プレゼンターはすべてのビューに通知する必要がありますが、モデルには通知しません。ただし、変更されたばかりであっても、どのビューも変更通知をPresenterに送信することはできません。

プレゼンターは誰に通知し、誰に通知しないのですか？また、モデルは変更通知を送信する必要があるかどうかをどのように知るのでしょうか。結局のところ、それは変更されたばかりですが、必ずしも誰が知っているわけではありません。

1つの可能性は、すべての人（モデル、ビュー、およびプレゼンター）が変更通知を自由に送信できるようにすることですが、変更を最初にトリガーしたオブジェクトへの参照を通知内に保存します（これにより、通知をイベントオブジェクトにカプセル化します）。その後、すべてのオブジェクトは、変更の元のトリガーでない場合にのみ通知を送信します。しかし、それを行うためのより簡単でクリーンな方法はありますか？

4

1 に答える 1

1

これにアプローチする方法はいくつかありますが、私が推奨する 2 つはMediator Patternまたは何らかのタイプのEvent Aggregatorです。

Mediator パターンの背後にある考え方は、オブジェクトのコレクションが特定のシナリオでどのように相互作用するかをカプセル化できるようにする一方で、それらを相互に認識しないようにすることです。

このようなもの：

public class MyPresenterOne{
   public event EventHandler OnFoo;
}

public class MyPresenterTwo{
   public void DoStuff(){
      //Something interesting
   }
}

public class MyMediator{
   public MyMediator(MyPresenterOne p1, MyPresenterTwo p2){
      p1.OnFoo += (o, e) => p2.DoStuff();
   }
}

Event Aggregator は疎結合のパブリッシュ/サブスクライブ パラダイムであり、実際にはイベントではなくメッセージをリッスンします。一方の当事者は、あるタイプのメッセージに興味を示しますが、それがどこから来たのかはあまり気にしません。

public class MyPresenterOne{
   public MyPresenterOne(){
      EventAggregator.Publish("OnFoo");
   }
}

public class MyPresenterTwo{
   public MyPresenterTwo(){
      EventAggregator.Subscribe("OnFoo", () => {
         //Something interesting
      });
   }
}

メディエーターは実装が少し簡単で、意図は非常に明確ですが、関連するさまざまなコンポーネントについて詳しく知る必要があります。アイデアは、メディエーターを 1 つの巨大なメディエーターではなく、構成の特定のシナリオに集中させ続けることです。

Pub/Sub パラダイムは非常に洗練されており、コンポーネントを疎結合に保つのにうまく機能しますが、パブリッシュするメッセージの種類に関しては、さらに多くのことを考慮する必要があります。

于 2012-12-08T05:39:03.927 に答える