Muss jedes kleine Ereignis, das in einem Ereignis-Aggregator veröffentlicht wird, ein eigenes leeres CompositePresentationEvent sein?

Question

Ich versuche zu verstehen, wie die Ereignis-Aggregator-Muster aus Sicht der Architektur und des Designs. Ich habe noch nie Prism in WPF verwendet, aber ich studiere gerade, wie es auf MSDN funktioniert.

Es scheint mir, dass der Benutzer für jedes Ereignis ein neues Ereignisobjekt erstellen muss, das die CompositePresentationEvent . Es scheint auch, dass das neue Ereignisobjekt keine anderen Funktionen hat als die, von denen es geerbt hat (es hat normalerweise keinen Code für sich selbst).

So zum Beispiel:

A AddNewStuffEvent aussehen würde:

public class AddNewStuffEvent : CompositePresentationEvent<Object> {} //The end of the class

Für eine HealthChangeEvent :

public class HealthChangeEvent: CompositePresentationEvent<Object> {} //The end of the class

Für eine BookFlipEvent :

public class BookFlipEvent: CompositePresentationEvent<Object> {} //The end of the class

Für eine BookCloseEvent :

public class BookCloseEvent: CompositePresentationEvent<Object> {} //The end of the class

Und das kann ewig so weitergehen, bei jedem noch so kleinen Ereignis für BookOpenEvent , BookTearEvent , usw. In einem bestimmten Namespace-Ordner gibt es also eine ganze Menge von Ereignisklassen, und der Event Aggregator wird zur Laufzeit mit all diesen Ereignisobjekten geladen. Das heißt, jedes kleine Ereignis braucht eine leere Klasse? Funktioniert das so? Was könnte ein besserer Weg dafür sein?

Answer 1

Ja, jeder Ereignistyp benötigt seine eigene Klasse, die Sie definieren müssen.

Es scheint auch, dass das neue Ereignisobjekt keine anderen Funktionen hat, als die, die es geerbt hat von

Der Zweck besteht einfach darin, eine starke Typisierung für die Veranstaltung vorzunehmen. Das macht es einfacher, Code zu schreiben, um sie zu abonnieren. D.h., der abonnierende Code kann wie folgt geschrieben werden:

aggregator.GetEvent<AddNewStuffEvent>().Subscribe(Handler);

Dies ist ein besserer Ansatz als Alternativen, wie z. B. das Vertrauen auf "magische Fäden" in Form von aggregator.GetEvent("AddNewStuffEvent").Subscribe(Handler) (was zur Kompilierzeit nicht überprüft werden konnte.