Блог

Похоже, что большинство фреймворков MVVM используют производную ICommand, где они просто предоставляют делегаты методам Execute / CanExecute в представлении, вместо того, чтобы создавать новый класс и переопределять методы Execute / CanExecute.

Какой дизайн является лучшим? Передача делегатов метода или получение при предоставлении Execute / CanExecute для ICommand?

Кажется, вывод получил бы больше возможностей повторного использования команды в других представлениях и мог бы быть чище? Но для небольших операций выполнения / CanExecute накладные расходы на создание нового производного класса слишком велики, и лучше просто передать delgates методам в представлении?

Спасибо за любую информацию о лучших практиках.

Основное неудобство ICommand интерфейса заключается в том, что команда «похоронена» в другом экземпляре класса. Обычно вы хотите, чтобы команда работала с классом, который предоставляет ICommand свойство.

Классический RelayCommand , популяризированный Джошем Смитом, создается путем предоставления лямбда-выражений для методов Execute и CanExecute .

Используя лямбда-выражения для ваших ICommand методов, вы можете «поднять» команду обратно в класс, с которым выполняется действие. Альтернативой является либо тесная связь между классом command и управляемым классом, либо методы пересылки, которые отправляют операции обратно в класс, которому отдается команда.

Лямбда-выражение имеет разрешение на доступ к закрытым элементам, которые находятся в области видимости на момент сборки команды. Это значительно уменьшает неудобства, связанные с тем, что ICommand свойство должно быть отдельным экземпляром класса.

Тем не менее, достаточно общий ICommand , который использует общедоступный API класса для выполнения своего действия, также может быть полезным и повторно используемым шаблоном реализации.