0

イベントの公開とサブスクライブの複雑さを軽減するために、Eventaggregatorが単一のソースとして機能するという考えがあります。この点で他に何が理解できるか。コードによる例ではなく、一般的な説明のみが必要です。

4

2 に答える 2

0

EventAggregator MSDNページの最初の行から：

EventAggregatorサービスは、主にイベントのコンテナーであり、パブリッシャーとサブスクライバーを分離して、独立して進化させることができます。このデカップリングは、シェルまたはおそらく他のモジュールによって定義されたイベントに応答する新しいモジュールを追加できるため、モジュール化されたアプリケーションで役立ちます。

そのページの残りの部分を読んで、それがどのように機能するか、そしてそれがどのように使用されるかの例を理解してください。私が従うのが好きな一般的なルールは、Model-> ViewModel通信の場合、標準の.NETイベントは適切ですが、ViewModel-> ViewModel（またはModule-> Module）通信の場合（どちらも実際にはお互いを「知る」必要はありません）、 EventAggregatorは素晴らしいです。

于 2012-08-29T12:20:26.380 に答える
0

の考え方はEventAggregator、発生したイベントのソースオブジェクトを知る必要がないということです。通常、イベントをサブスクライブ/リッスンするには、ソースオブジェクトをクラスに持ってきてから、次のようにイベントをサブスクライブする必要があります。

// Object will raise event
public class EventSourceClass
{
   public event EventHandler<EventArgs> OnMyEvent;
}

今-イベントをサブスクライブしたいクラス/オブジェクトは、どういうわけか次のようなクラスを知っている必要がありEventSourceClassます：

// Object will listen to events from very specific (EventSourceClass) class
public class EventListenerClass
{
   ...
   EventSourceClass eventSourceClass = new EventSourceClass(....);
   eventSourceClass.OnMyEvent += ......
   ...
 }

EventAggregator単純にするだけです。

  • イベントを説明するクラスを定義します（クラスはから継承しCompositePresentationEvent<>ます。
  • 次に、イベントレイザークラスでは、イベントEventAggregator.GetEvent<event-type>().Publish(build-your-event-here)をレイズする準備ができたときに実行します。

  • そして、イベントリスナークラスではEventAggregator.GetEvent<event-type>().Subscribe(function-that-will-start-to-work)、このイベントに参加します。

    イベントを発生させるクラスもイベントリスナークラスもお互いを知っている必要はなく、どちらもEventAggregator最終的なイベント通過/イベントバスオブジェクトのみを知っている必要があるため、ソースオブジェクトをリスナーから切り離すと呼ばれます。

    この情報がお役に立てば幸いです。

于 2012-08-30T08:32:31.970 に答える