EventAggregator vs CompositeCommand

Question

J'ai travaillé mon chemin à travers le guidage Prism et je pense avoir compris la plupart de leurs véhicules de communication.

La commande est très simple, il est donc clair que DelegateCommand sera utilisé uniquement pour connecter la vue à son modèle.

Il est un peu moins clair, quand il s'agit de la communication entre modules, d'utiliser spécifiquement EventAggregation par rapport aux commandes composites.

L'effet pratique est le même, par ex.

• Vous publiez un événement -> tous les abonnés reçoivent un avis et d'exécuter du code en réponse
• Vous exécutez une commande composite -> toutes les commandes enregistrées sont exécutées et avec elle leur code ci-joint

Les deux travaux sur le modèle de "fire and forget", c'est-à-dire qu'ils ne se soucient pas des réponses de leurs abonnés après le déclenchement de l'événement/l'exécution des commandes.

J'ai du mal à voir une différence pratique dans l'utilisation bien que je comprenne que la mise en œuvre des deux (sous le capot) est très différente.

Alors devrions-nous penser à ce que cela signifie réellement - Événement? Est-ce quand quelque chose arrive (un événement se produit)? Quelque chose que l'utilisateur n'a pas demandé directement comme une «demande Web terminée»?

Et la commande? Est-ce que cela signifie qu'un utilisateur a cliqué sur quelque chose et a donc émis une commande à notre application, demandant un service directement?

Est-ce cela? Ou existe-t-il d'autres moyens de déterminer quand utiliser l'un de ces moyens de communication plutôt que l'autre? Les conseils, bien que l'une des meilleures documentations que je lis, ne donne aucune explication spécifique. Donc, j'espère que les personnes impliquées dans/utilisant Prism peuvent aider à faire la lumière sur ce sujet.

Answer 1

Il existe deux différences principales entre les deux.

1. CanExécute pour les commandes. Une commande peut dire si oui ou non il est valable pour l'exécution en appelant Command.RaiseCanExecuteChanged() et ayant son délégué CanExecute return false. Si l'on considère le cas d'un « Enregistrer tout » CompositeCommand compositing plusieurs commandes « Enregistrer », mais un des commandes en disant qu'il ne peut pas exécuter , le bouton Enregistrer tout se désactive automatiquement (nice!).
2. EventAggregator est un modèle de messagerie et les commandes sont un modèle de commande . Bien que CompositeCommands ne sont pas explicitement un modèle d'interface utilisateur, il est implicitement (généralement ils sont connectés à une action d'entrée , comme un clic de bouton). EventAggregator est pas de cette façon - une partie de l'application augmenter efficacement un événement EventAggregator : processus d'arrière-plan, ViewModels, etc. Il est une avenue entremise d'un courtier pour la messagerie dans votre application avec le support pour des choses telles que le filtrage, exécution de thread d'arrière-plan, etc.

Espérons que cela aide à expliquer les différences. Il est plus difficile de dire quand utiliser chacun, mais généralement j'utilise la règle du si c'est l'interaction de l'utilisateur qui déclenche l'événement, utilisez une commande pour autre chose, utilisez EventAggregator.

Espérons que cela aide.

Answer 2

De plus, il y a une plus importante différence: Avec la mise en œuvre actuelle, un événement de la EventAggregator est asynchrone, tandis que le CompositeCommand est synchrone. Si vous souhaitez implémenter quelque chose comme "notifier que l'événement X est arrivé, faire quelque chose qui repose sur les gestionnaires d'événements pour que l'événement X ait été exécuté", vous devez faire quelque chose comme Application.DoEvents() ou utiliser CompositeCommands.