CompositeWPF: EventAggregator - когда использовать?

Я смотрел Composite Application Library, и это здорово, но мне трудно решить, когда использовать EventAggregator... или, вернее, - когда НЕ использовать его.

Глядя на пример StockTraderRI, я еще более смущен. В некоторых случаях они используют EventAggregator и "классические" события в других случаях (например, в интерфейсе IAccountPositionService).

Я уже решил использовать его для связи с тяжелой рабочей задачей, которая должна работать на фоновом потоке. В этом случае EventAggregator предлагает сортировку потоков за кулисами, поэтому мне не о чем беспокоиться. Кроме того, мне нравится развязка такого подхода.

Итак, мой вопрос: когда я начал использовать EventAggregator в своем приложении, почему бы не использовать его для всех пользовательских событий?

Ответ 1

Это хороший вопрос. В Composite WPF (Prism) существует 3 возможных способа связи между частями вашего приложения. Один из способов - использовать Commanding, который используется только для передачи действий, инициированных UI, по пути к фактическому коду, реализующему это действие. Другим способом является использование общих служб, где несколько частей содержат ссылку на одну и ту же службу (Singleton), и они обрабатывают различные события этой службы классическим способом. Для отключенной и асинхронной связи, как вы уже сказали, лучший способ - использовать агрегатор событий (который следует за шаблоном Мартина Фаулера).

Теперь, когда и не использовать его:

  • Используйте его, когда вам нужно общаться между модулями. (например, модуль Task должен быть уведомлен о том, что Task создается любым другим модулем).
  • Используйте его, когда у вас есть несколько возможных приемников или источников одного и того же события. Например, у вас есть список объектов, и вы хотите обновлять его, когда объект этого типа сохраняется или создается. Вместо того, чтобы ссылаться на все открытые экраны редактирования/создания, вы просто подписаны на это конкретное событие.
  • Не используйте его, когда вам нужно подписываться только на обычные события в области представления представления модели. Например, если ваш ведущий прослушивает изменения в Модели (например, Model реализует INotifyPropertyChanged), и вашему Presenter необходимо реагировать на такие изменения, лучше, чтобы ваш Presenter обрабатывал непосредственно событие PropertyChanged модели вместо того, чтобы переадресовывать такие события через Агрегатор событий. Таким образом, если оба отправителя и получателя находятся в одном блоке, нет необходимости "транслировать" такие события на все приложение.

Надеюсь, это ответит на ваш вопрос.