Vous avez beaucoup de questions dans votre message auxquelles vous pouvez répondre "cela dépend de votre application", mais je vais essayer d'y répondre.
Une chose que je vois le plus souvent avec EventAggregator est abus. De nombreuses personnes utilisent EventAggregator d'une manière qui rend l'éditeur et l'abonné dépendants l'un de l'autre. Cela m'amène à mon premier conseil:
Ne supposez jamais qu'il existe des sous-composants à un événement.
EventAggregator est utile pour des événements publier d'autres vues pourrait intéresser. Par exemple, dans notre application, nous permettons à un utilisateur de changer le nom de quelqu'un. Ce nom pourrait être affiché sur d'autres vues déjà ouvertes dans l'application (nous avons une interface utilisateur à onglets). Notre cas d'utilisation était que nous souhaitions que ces interfaces soient mises à jour lorsque le nom était modifié. Nous avons donc publié un événement "UserDataChanged" afin que les vues ouvertes puissent s'abonner et rafraîchir leurs données, mais si aucune vue n'était ouverte, aucun abonné n'a été informé.
Événements .NET Favor sur les événements EventAggregator le cas échéant
Une autre erreur que je vois est souvent un processus métier qui est mis en œuvre à l'aide EventAggregator où les données sont envoyées à une partie centrale et que les réponses du parti, tout en utilisant EventAggregator . Cela conduit à certains effets secondaires que vous voudrez probablement éviter.
Une variation sur ce que je vois beaucoup est la communication d'une vue parent à une sous-vue, ou vice-versa. Quelque chose comme "TreeItemChecked" ou "ListViewItemSelected". C'est une situation où les événements .NET traditionnels seraient utilisés, mais un auteur a décidé que s'ils ont un marteau (EventAggregator), tout (Events) ressemble à un clou.
Vous avez demandé la modélisation de la EventAggregator et je dirais ceci: le EventAggregator n'est particulier en ce sens qu'elle permet de découplage et ne crée pas de fortes références à des événements (en évitant les fuites de mémoire, etc.). A part cela, c'est vraiment juste une très légère variation du Observer Pattern. Cependant, vous modélisez les Observateurs pour modéliser l'EventAggregator dans le type de diagramme que vous essayez de créer.
Quant à votre question sur en vous assurant un certain module ou une autre est abonnée à un événement: vous ne. Si vous devez vous assurer qu'il y a des abonnés, vous ne devez pas utiliser EventAggregator. Dans ces cas, je recommanderais un service fonctionnant dans votre application que les modules peuvent récupérer de votre conteneur et utiliser ou autre chose similaire. La chose à garder à l'esprit au sujet de vos modules est que vous devriez être capable de supprimer complètement un et le reste de votre application fonctionne normalement. Si ce n'est pas le cas, vous avez une dépendance de module (préférable d'être évité, mais compréhensible), ou des modules dépendants devraient être combinés en un.
Un excellent conseil. Je vous remercie. – Raj