В вашем посте много вопросов, на которые можно ответить «это зависит от вашего заявления», но я постараюсь ответить на некоторые из них.
Одна вещь, которую я чаще всего вижу с EventAggregator - это злоупотребление . Многие люди используют EventAggregator таким образом, что и издатель, и подписчик зависят друг от друга. Это подводит меня к моему первому совету:
Никогда не предполагайте, что есть какие-либо подписчики на событие.
EventAggregator полезен для публикации событий других представлений может заинтересовать . Например, в нашем приложении мы позволяем пользователю изменять чье-либо имя. Это имя может отображаться в других представлениях, уже открытых в приложении (у нас есть пользовательский интерфейс с вкладками). Наш вариант использования состоял в том, что мы хотели, чтобы эти пользовательские интерфейсы обновлялись при изменении имени, поэтому мы опубликовали событие «UserDataChanged», чтобы открытые представления могли соответствующим образом подписываться и обновлять свои данные, но если никакие открытые представления не интересовали эти данные, подписчики не были уведомлены.
При необходимости используйте события .NET поверх событий EventAggregator
Другая ошибка, которую я часто вижу, - это бизнес-процесс, который реализуется с помощью EventAggregator, когда данные отправляются центральной стороне, а затем эта сторона отвечает, причем все с помощью EventAggregator. Это приводит к некоторым побочным эффектам, которых вы, вероятно, хотели бы избежать.
Разновидностью, которую я вижу много, является связь от родительского представления к вложенному представлению или наоборот. Что-то вроде «TreeItemChecked» или «ListViewItemSelected». В этой ситуации будут использоваться традиционные .NET события, но автор решил, что если у них есть молоток (EventAggregator), все (события) выглядит как гвоздь.
Вы спрашивали о моделировании EventAggregator , и я бы сказал так: EventAggregator уникален только тем, что он позволяет разъединять и не создает сильных ссылок на события (избегая утечек памяти и т. Д.). Кроме этого, это действительно очень небольшое изменение паттерна наблюдателя . Однако вы моделируете Observers так, как вы бы моделировали EventAggregator на диаграмме любого типа, которую вы пытаетесь создать.
Что касается вашего вопроса о , убедитесь, что тот или иной модуль подписан на событие : вы не . Если вам нужно убедиться, что подписчики есть, вы не должны использовать EventAggregator. В этих случаях я бы порекомендовал сервис, работающий в вашем приложении, который модули могут извлекать из вашего контейнера и использовать или другие подобные вещи.
При работе с модулями следует помнить, что вы должны иметь возможность полностью удалить одно и все остальное приложение нормально работает . Если это не так, у вас либо есть зависимость от модуля (лучше избегать, но понятно), либо зависимые модули должны быть объединены в один.