EventAggregator по сравнению с CompositeCommand
В то время как существуют, конечно, преимущества для имения бизнес-логики на прикладном уровне, я хотел бы указать, что языки/платформы, кажется, изменяют более часто тогда базы данных.
Некоторые системы, которые я поддерживаю, прошли следующий UIs за прошлые 10-15 лет: Формы Oracle / Визуальный Основной CGI / CGI Perl / Сервлет ASP/Java. Одна вещь, которая не изменилась - реляционная база данных и хранимые процедуры.
1 ответ
Между этими двумя есть два основных различия:
- CanExecute для команд . Команда могу сказать, действительно ли это для исполнения по телефону Command.RaiseCanExecuteChanged () и наличие делегата CanExecute вернуть ложь. Если учесть случай "Сохранить все" CompositeКоманда, составляющая несколько "Сохранить" команды, но одна из команды говорят, что это не может выполнить, кнопка Сохранить все будет автоматически отключается (хорошо!).
- EventAggregator - это система обмена сообщениями. шаблон и команды - это Командующий шаблон . Хотя CompositeCommands явно не шаблон пользовательского интерфейса, это неявно так (обычно они подключены к действие ввода, например нажатие кнопки). EventAggregator не такой - любая часть приложения эффективно поднять EventAggregator событие: фоновые процессы, ViewModels и т. Д. Это проспект для обмена сообщениями через ваше приложение с поддержкой для таких вещей, как фильтрация, выполнение фонового потока и т. д.
Надеюсь, это поможет объяснить различия. Сложнее сказать, когда использовать каждый из них, но обычно я использую практическое правило: если событие вызывает взаимодействие с пользователем, используйте команду для чего-либо еще, используйте EventAggregator .
Надеюсь, это поможет .