WPF ICommand против RoutedCommand

Question

Давайте иметь свойство кнопки Command, привязанное к пользовательской команде.

Когда я должен реализовать ICommand и когда происходит от RoutedCommand? Я вижу, что RoutedCommand реализует ICommand .

В каком случае мне может понадобиться ICommand? А как насчет модели MVVM? Какой из них лучше подходит для этой цели?

Answer 1

Как вы заметили, класс RoutedCommand является реализацией интерфейса ICommand, его основное отличие заключается в том, что его функция аналогична функции RoutedEvent:

Методы Execute и CanExecute в RoutedCommand не содержат логику приложения для команды, как в случае типичной ICommand, но, скорее, эти методы вызывают события, которые пересекают дерево элементов в поисках объекта с CommandBinding. Обработчики событий, прикрепленные к CommandBinding, содержат логику команды.

Метод Execute вызывает события PreviewExecuted и Executed. Метод CanExecute вызывает события PreviewCanExecute и CanExecute.

В случае, если вам не нужно поведение RoutedCommand, вы будете смотреть на собственную реализацию ICommand. Что касается паттерна MVVM, я не могу сказать, что одно решение, похоже, у каждого своя методология. Однако вот несколько подходов к этой проблеме, с которыми я столкнулся:

• Использование RoutedCommands с ViewModel в WPF
• Релейная логика команд
• Простая команда (почти идентична команде реле, но стоит прочитать)

Answer 2

Единственное, что я хотел бы добавить к ответу Рича Макгуайра, это то, что RoutedCommands (и их более распространенный потомок RoutedUICommand должны быть связаны с обработчиками событий для корректной работы.

В большинстве реализаций MVVM я сталкивался с попыткой использовать привязку к ViewModel, и, таким образом, ViewModel (а не View) владеет логикой CanExecute / Execute.

Напротив, обработчики событий переносят эту нагрузку на View. Затем обработку можно распространить на ViewModel, но это означает немного более высокую степень связи между ViewModel и View (приведение + вызов метода и т. Д.).