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

Question

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

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

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

Answer 3

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

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

Answer 4

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

Answer 5

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