EventAggregator против CompositeCommand - PullRequest
14 голосов
/ 05 октября 2009

Я прошел путь через руководство Призмы и думаю, что я понял большинство их средств коммуникации.

Командование очень простое, поэтому ясно, что DelegateCommand будет использоваться только для соединения View с его моделью.

Несколько менее понятно, когда речь идет о кросс-модульной связи, особенно когда использовать EventAggregation над составными командами.

Практический эффект тот же, например

  • Вы публикуете событие -> все подписчики получают уведомление и исполняют код в ответ
  • Вы выполняете составную команду -> выполняются все зарегистрированные команды и вместе с ними прикрепленный код

Оба работают по принципу «стреляй и забывай», то есть они не заботятся о каких-либо ответах своих подписчиков после запуска события / выполнения команд.

Мне трудно увидеть практическое различие в использовании, хотя я понимаю, что реализация обоих (под капотом) сильно отличается.

Так что мы должны думать о том, что это на самом деле означает - Событие? Это когда что-то случается (происходит событие)? Что-то, что пользователь не запрашивал напрямую, например, «веб-запрос завершен»?

а командование? Означает ли это, что пользователь что-то щелкнул и, таким образом, дал команду нашему приложению, запросив сервис напрямую?

Это так? Или есть другие способы определить, когда использовать один из этих транспортных средств связи над другим. Руководство, хотя и является одной из лучших документов, которые я прочитал, не дает конкретного объяснения.

Поэтому я надеюсь, что люди, вовлеченные в / использующие Prism, могут помочь пролить некоторый свет на это.

Ответы [ 2 ]

15 голосов
/ 05 октября 2009

Есть два основных различия между этими двумя.

  1. CanExecute для команд . Команда можно сказать, действительно ли это для исполнения по телефону Command.RaiseCanExecuteChanged () и имеющий свой делегат CanExecute вернуть ложь. Если вы считаете, случай "Сохранить все" CompositeCommand составление нескольких Команды «Сохранить», но одна из команды говорят, что это не может выполнить кнопку Сохранить все автоматически отключить (приятно!).
  2. EventAggregator - это обмен сообщениями шаблон и команды являются Командный образец . Хотя CompositeCommands не являются явно шаблон пользовательского интерфейса, это неявно так (как правило, они подключены к действие ввода, как нажатие кнопки). EventAggregator не так - любая часть приложения эффективно поднять EventAggregator событие: фоновые процессы, ViewModels и т. Д. Это посредник проспект для обмена сообщениями через ваше приложение с поддержкой для таких вещей, как фильтрация, фоновое выполнение потока и т. д.

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

Надеюсь, это поможет.

6 голосов
/ 06 сентября 2010

Кроме того, есть еще одно важное отличие: в текущей реализации событие из EventAggregator равно асинхронно , а CompositeCommand - синхронно .

Если вы хотите реализовать что-то вроде «уведомить о том, что событие X произошло; сделать что-то, что зависит от обработчиков событий для выполнения события X», вы должны либо сделать что-то вроде Application.DoEvents (), либо использовать CompositeCommands.

...