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

Question

Я искал библиотеку составных приложений , и это здорово, но у меня возникают проблемы с выбором, когда использовать EventAggregator ... или скорее - когда НЕ использовать его.

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

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

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

Answer 1

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

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

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

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