CompositeWPF: EventAggregator - quand utiliser?

Question

J'ai regardé dans le Composite Application Library, et c'est génial, mais j'ai du mal à décider quand utiliser l'EventAggregator ... ou plutôt - quand ne pas l'utiliser.

En regardant l'exemple StockTraderRI, je suis encore plus confus. Ils utilisent EventAggregator dans certains cas, et des événements "classiques" dans d'autres cas (dans l'interface IAccountPositionService, par exemple).

J'ai déjà décidé de l'utiliser pour la communication avec une lourde tâche de travail, qui devrait fonctionner sur un fil de fond. Dans ce cas, l'EventAggregator offre la gestion des threads en coulisse, donc je n'ai pas à m'inquiéter beaucoup à ce sujet. En plus de cela, j'aime le découplage que cette approche offre. Donc, ma question est: Quand j'ai commencé à utiliser l'EventAggregator dans mon application, pourquoi ne pas l'utiliser pour tous les événements personnalisés?

Answer 1

C'est une bonne question. Dans Composite WPF (Prism), il y a 3 façons possibles de communiquer entre les parties de votre application. Une façon consiste à utiliser Commanding, qui est utilisé uniquement pour transmettre les actions déclenchées par l'interface utilisateur sur le code réel implémentant cette action. Une autre méthode consiste à utiliser les services partagés, où plusieurs parties contiennent une référence au même service (Singleton) et gèrent les différents événements de ce service de manière classique. Pour la communication déconnectée et asynchrone, comme vous l'avez déjà indiqué, le meilleur moyen est d'utiliser Event Aggregator (qui suit de près le modèle de Martin Fowler).

Maintenant, quand et de ne pas l'utiliser:

1. utiliser lorsque vous avez besoin de communiquer entre les modules. (par exemple, un module de tâche doit être notifié lorsqu'une tâche est créée par un autre module).
2. Utilisez-le lorsque vous avez plusieurs récepteurs ou sources possibles du même événement. Par exemple, vous avez une liste d'objets que vous souhaitez actualiser chaque fois qu'un objet de ce type est enregistré ou créé. Au lieu de conserver des références à tous les écrans d'édition/création ouverts, vous vous abonnez simplement à cet événement spécifique. Ne l'utilisez pas lorsque vous ne devez vous abonner qu'à des événements normaux dans la zone Model View Presenter. Par exemple, si votre présentateur écoute les modifications du modèle (par exemple, le modèle implémente INotifyPropertyChanged) et que votre Presenter doit réagir à de telles modifications, il est préférable que votre Presenter gère directement l'événement PropertyChanged du modèle au lieu de détourner ces événements via le Agrégateur d'événements. Ainsi, si l'expéditeur et le destinataire sont dans la même unité, il n'est pas nécessaire de "diffuser" de tels événements à l'ensemble de l'application.

J'espère que cela répond à votre question.