Почему ICommand лучше кода за вызовом виртуальной машины?

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

Он хочет добавить кнопку, а затем сделать для нее событие в коде. Затем из события он хочет вызвать метод в ViewModel.

Я дал ему очевидный ответ: Это добавляет связь между View и ViewModel. Но он утверждал, что View и ViewModel уже связаны. (Мы устанавливаем наше представление DataContext в ViewModel в коде просмотра позади: DataContext = new MyViewModel();

Да, я сказал ему, что его способ добавляет "больше сцепления", но это звучало немного хромой даже для меня.

Итак, я знаю, что ICommand - это чистый путь, и я делаю так. Но что еще может купить ICommand, не используя уже существующую связь?

ОТВЕТЫ

Ответ 1

  • Это не о развязывании, а о том, насколько глубоко вы можете проникнуть внутрь своей иерархии ModelView: не накачка событий, а маршрутизация событий, встроенная в инфраструктуру.

  • Об управлении UI: команда имеет состояние (CanExecute), если назначить команду элементу управления, если состояние команды становится false, управление становится отключенным. Это дает вам мощный интерфейс управления пользовательским интерфейсом, избегая большого количества спагетти-кодирования, особенно для сложного интерфейса.

Ответ 2

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

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

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

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

Ответ 3

ICommand также может предоставить вам место для обработки, или не может быть использована конкретная кнопка. это будет обрабатываться методом canececute.

Ответ 4

Вы можете привязать метод CanExecute команды к свойствам элемента управления, а также Command инкапсулирует действие с хорошим способом. По моему мнению, этот подход имеет большой смысл, потому что у вас есть как условие, так и действие выполнения в одной абстракции, что упрощает понимание и проверку.

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

Ответ 5

Одна вещь, которую я не вижу в предыдущих ответах, заключается в том, что использование ICommand способствует повторному использованию кода, позволяя использовать одно и то же действие различными компонентами GUI. Например, если у меня была команда, которая должна привести к открытию окна, и эта команда может быть вызвана в три или для разных экранов в приложении, реализация ICommand позволяет мне определить эту логику в одном месте. С обработчиками событий с кодом-кодом мне приходится копировать и вставлять избыточный код в нарушение DRY (иначе мне пришлось бы сворачивать мою собственную реализацию, абстрагируясь до класса, и в этот момент я мог бы также использовать ICommand).