EventAggregator vs CompositeCommand

Question

Mi sono fatto strada attraverso la guida Prism e penso di aver afferrato la maggior parte dei loro veicoli di comunicazione.

Il comando è molto semplice, quindi è chiaro che il DelegateCommand verrà utilizzato solo per collegare la vista con il relativo modello.

È un po 'meno chiaro quando si tratta di cross Module Communication, in particolare quando utilizzare EventAggregation su Composite Commands.

L'effetto pratico è lo stesso ad es.

• Si pubblica un evento -> tutti gli abbonati ricevono preavviso e eseguire codice in risposta
• si esegue un comando composito -> tutti i comandi registrati vengono eseguiti e con essa il loro codice allegato

Entrambi lavorano sulla falsariga di "fire and forget", cioè non si preoccupano delle risposte dei propri abbonati dopo l'attivazione dell'evento/l'esecuzione dei comandi.

Ho difficoltà a vedere una differenza pratica nell'uso anche se capisco che l'implementazione di entrambi (sotto il cofano) è molto diversa.

Quindi dovremmo pensare a cosa significa in realtà - Evento? È così quando succede qualcosa (si verifica un evento)? Qualcosa che l'utente non ha richiesto direttamente come una "richiesta web completata"?

E comando? Significa che un utente ha fatto clic su qualcosa e quindi ha emesso un comando per la nostra applicazione, richiedendo direttamente un servizio?

È tutto? Oppure ci sono altri modi per determinare quando utilizzare uno di questi veicoli di comunicazione rispetto all'altro. La guida, sebbene sia una delle migliori documentazioni che ho letto, non fornisce alcuna spiegazione specifica.

Quindi spero che le persone coinvolte/nell'utilizzo del Prisma possano aiutare a far luce su questo.

Answer 1

Ci sono due differenze principali tra questi due.

1. CanExecute for Commands. Un comando può dire se è valido o meno per l'esecuzione chiamando Command.RaiseCanExecuteChanged() e con il suo delegato CanExecute return false. Se si considera il caso di un "Salva tutto" CompositeCommand compositing diversi comandi "Salva", ma uno dei comandi dicendo che non può eseguire, il pulsante Save All saranno disabilitare automaticamente (bello!).
2. EventAggregator è un modello di messaggistica e i comandi sono un modello di comando . Sebbene CompositeCommands non siano esplicitamente un modello dell'interfaccia utente, è implicitamente (in genere sono collegati a un'azione di input , come un clic del pulsante). EventAggregator non è in questo modo - qualsiasi parte dell'applicazione effettivamente generare un EventAggregator evento: i processi in background, ViewModels, ecc E 'un viale mediato per la messaggistica in tutta l'applicazione con il supporto per cose come il filtraggio, esecuzione del thread in background, ecc.

Spero che questo aiuti a spiegare le differenze. È più difficile dire quando utilizzarli, ma in genere io uso la regola empirica che è se è l'interazione dell'utente che solleva l'evento, usa un comando per qualsiasi altra cosa, usa EventAggregator.

Spero che questo aiuti.

Answer 2

Inoltre, v'è un altro importante differenza: Con l'implementazione corrente, un evento dal EventAggregator è asincrona, mentre il CompositeCommand è sincrono.

Se si desidera implementare qualcosa come "notificare che evento X è successo, fare qualcosa che si basa sui gestori di eventi per l'evento X da eseguire", si deve fare qualcosa come Application.DoEvents() o utilizzare CompositeCommands.