CompositeWPF: EventAggregator - wann zu verwenden?

Question

Ich habe in der Composite Application Library gesucht, und es ist großartig, aber ich habe Probleme zu entscheiden, wann der EventAggregator zu verwenden ... oder besser gesagt - wenn Sie es nicht verwenden.

Betrachtet man das Beispiel von StockTraderRI, bin ich noch verwirrter. Sie verwenden in einigen Fällen den EventAggregator und in anderen Fällen "klassische" Ereignisse (z. B. in der IAccountPositionService-Schnittstelle).

Ich habe mich bereits entschieden, es für die Kommunikation mit einem schweren Arbeitstask zu verwenden, der auf einem Hintergrundthread ausgeführt werden sollte. In diesem Fall bietet der EventAggregator das Marshalling von Threads hinter den Kulissen, so dass ich mir darüber keine Gedanken machen muss. Außerdem gefällt mir die Entkopplung, die dieser Ansatz bietet.

Also meine Frage ist: Wenn ich den EventAggregator in meiner Anwendung verwendet habe, warum nicht für alle benutzerdefinierte Ereignisse verwenden?

Answer 1

Das ist eine gute Frage. In Composite WPF (Prism) gibt es drei Möglichkeiten, um zwischen Teilen Ihrer App zu kommunizieren. Eine Möglichkeit besteht darin, Commanding zu verwenden, das nur dazu verwendet wird, von der Benutzeroberfläche ausgelöste Aktionen an den eigentlichen Code weiterzuleiten, der diese Aktion implementiert. Eine andere Möglichkeit besteht darin, Shared Services zu verwenden, bei denen mehrere Teile einen Verweis auf den gleichen Dienst (Singleton) enthalten und sie verschiedene Ereignisse auf diesem Dienst auf klassische Weise behandeln. Für die getrennte und asynchrone Kommunikation ist, wie Sie bereits sagten, der beste Weg, den Ereignisaggregator zu verwenden (der dem Muster von Martin Fowler genau folgt).

Nun, wenn sie und es nicht zu benutzen:

1. es verwenden, wenn Sie zwischen den Modulen kommunizieren müssen. (Beispielsweise muss ein Taskmodul benachrichtigt werden, wenn eine Task von einem anderen Modul erstellt wird).
2. Verwenden Sie es, wenn Sie mehrere mögliche Empfänger oder Quellen desselben Ereignisses haben. Beispielsweise haben Sie eine Liste von Objekten, die Sie jedes Mal aktualisieren möchten, wenn ein Objekt dieses Typs gespeichert oder erstellt wird. Anstatt Referenzen auf alle geöffneten Edit/Create-Bildschirme zu halten, abonnieren Sie einfach dieses spezielle Ereignis.
3. Verwenden Sie es nicht, wenn Sie nur normale Ereignisse im Bereich "Model View Presenter" abonnieren müssen. Wenn beispielsweise Ihr Moderator auf Änderungen im Modell hört (z. B. das Modell implementiert INotifyPropertyChanged) und Ihr Presenter auf solche Änderungen reagieren muss, ist es besser, dass Ihr Presenter das PropertyChanged-Ereignis des Modells direkt handhabt, anstatt solche Ereignisse durch das Modell zu leiten Ereignisaggregator Wenn also sowohl Sender als auch Empfänger in derselben Einheit sind, müssen solche Ereignisse nicht an die gesamte Anwendung "gesendet" werden.

Ich hoffe, das beantwortet Ihre Frage.