CompositeWPF: EventAggregator - quando usare?

Question

Ho cercato il Composite Application Library ed è fantastico, ma ho difficoltà a decidere quando utilizzare EventAggregator ... o meglio - quando NON lo uso.

Guardando all'esempio StockTraderRI, sono ancora più confuso. Stanno utilizzando EventAggregator in alcuni casi e eventi "classici" in altri casi (ad esempio l'interfaccia IAccountPositionService).

Ho già deciso di utilizzarlo per la comunicazione con un'attività di lavoro pesante, che dovrebbe essere eseguito su un thread in background. In questo caso, EventAggregator offre il marshalling dei thread dietro le quinte, quindi non mi devo preoccupare molto di questo. Oltre a ciò mi piace il disaccoppiamento offerto da questo approccio.

Quindi la mia domanda è: quando ho iniziato a utilizzare EventAggregator nella mia applicazione, perché non usarlo per tutti gli eventi personalizzati?

Answer 1

Questa è una buona domanda. In Composite WPF (Prism) ci sono 3 modi possibili per comunicare tra parti della tua app. Un modo è utilizzare il comando, che viene utilizzato solo per passare azioni attivate dall'interfaccia utente lungo il percorso verso il codice effettivo che implementa tale azione. Un altro modo è utilizzare i servizi condivisi, dove più parti contengono un riferimento allo stesso servizio (Singleton) e gestiscono vari eventi su quel servizio nel modo classico. Per le comunicazioni disconnesse e asincrone, come hai già detto, il modo migliore è utilizzare l'aggregatore di eventi (che segue da vicino il modello di Martin Fowler).

Ora, quando e non usarlo:

1. usarlo quando avete bisogno di comunicare tra i moduli. (per esempio, un modulo Task deve essere avvisato quando un Task viene creato da un altro modulo).
2. Utilizzarlo quando si dispone di più destinatari o sorgenti dello stesso evento. Ad esempio, si dispone di un elenco di oggetti e si desidera aggiornarlo ogni volta che un oggetto di quel tipo viene salvato o creato. Invece di conservare riferimenti a tutte le schermate di modifica/creazione aperte, ti basta iscriverti a questo evento specifico.
3. Non utilizzarlo quando è necessario abbonarsi agli eventi normali nell'area Presentazione modello. Ad esempio, se il relatore ascolta modifiche nel modello (ad esempio, il modello implementa INotifyPropertyChanged) e il Presenter deve reagire a tali modifiche, è meglio che il Presenter gestisca direttamente l'evento PropertyChanged del modello invece di deviare tali eventi attraverso il Aggregatore di eventi. Pertanto, se sia il mittente che il destinatario si trovano nella stessa unità, non è necessario "trasmettere" tali eventi all'intera applicazione.

Spero che questo risponda alla tua domanda.