C #: Какую ценность добавляет командование?

2

При изучении фреймворков MVC для flex, as3, silverlight и wpf... появляется общая концепция ICommand/commanding... Может ли кто-нибудь объяснить преимущество использования ICommand/Execute()?

Где я не вижу добавленную стоимость - Почему контроллер не может сопоставить ввод (т.е. событие click) с правильным методом внутри модели? Я предполагаю, что это потому, что командование покупает вам что-то - например, удаляет бизнес-логику из контроллера/потенциального обработчика событий в контроллере.

спасибо.

  • 0
    Это один из тех вопросов, заставляет вас идти «да, почему все это делают?» Я с нетерпением жду исчерпывающего ответа ...
  • 0
    Первые два ответа меня не устраивают, жду большего
Теги:
wpf
silverlight
actionscript-3

3 ответа

8
Лучший ответ

Здесь несколько случаев, которые демонстрируют команды значений, добавляют:

  • Предположим, что у вас простая форма с текстовым полем и кнопкой "Отправить". Вы хотите, чтобы кнопка включалась только в том случае, если текст вводится в текстовое поле. С командами все, что вам нужно сделать, это реализовать метод CanExecute (вернуть true или false в зависимости от значения в текстовом поле). Рамка автоматически отключит/активирует кнопку. При подходе с кодом (или контроллером) вам придется писать код кнопкой включения/выключения вручную.
  • Предположим, что позже вы решили, что вам не нравится управление кнопками, которое вы использовали, и решили переключиться на новый элемент управления (будучи кнопкой или чем-то более экзотическим) из другой библиотеки. Все, что вам нужно сделать, это внести изменения в XAML. Любой элемент управления, который поддерживает привязку команды, будет знать, что делать. В подходе с обратным кодом вы также должны изменить свой обработчик нажатия кнопки (поскольку новый элемент управления, вероятно, потребует другую подпись обработчика событий)
  • Предположим, что позже вы решите добавить флажок в текстовое поле, которое визуально укажет пользователю, допустимо ли содержимое этого поля. Все, что вам нужно сделать, это привязать этот новый флажок к вашей команде CanExecute, и теперь у вас есть два элемента управления, которые автоматически изменят их внешний вид в зависимости от того, подана ли форма. При добавлении кода (или контроллера) добавление нового элемента управления потребует добавления дополнительного кода.
  • Предположим, вы хотите проверить свое действие. Поскольку команды не зависят от каких-либо визуальных элементов и не нуждаются в них, вы можете легко написать unit test, который не потребует нажатия пользователем каких-либо кнопок или ввода любого текста. С подходом контроллера вы должны эмулировать события контроллера и высмеивать представление.

Подведение итогов

Команды обеспечивают четко определенный интерфейс между бизнес-логикой и презентацией. Разработчик бизнес-логики не заботится о том, как визуально будет выполняться определенное действие (например, команда). Он просто обеспечивает реализацию действия и возможность для презентации запрашивать состояние действия. Ему все равно, какой конкретный элемент (или элементы) пользовательского интерфейса инициирует это действие, как точно (в) способность выполнить это действие будет отражать в пользовательском интерфейсе, и какие изменения пользовательского интерфейса могут пройти в будущем. В то же время дизайнеру презентации не нужно ничего знать о обработчиках событий, контроллерах и т.д. У него есть команда, и он подключает его к любому элементу (или элементам) пользовательского интерфейса, который он выбирает, без необходимости вообще обращаться к С# -коду,

  • 0
    Вау, отличный ответ. спасибо PL
  • 0
    +1 за четкие конкретные примеры того, почему командование является хорошей практикой. Я использую это сам, но я часто находил людей, поддерживающих это, чтобы дать общие причины и пропустить ценность примера реального мира.
1

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

  • Прикрепите обработчик события в коде.
  • Создайте команду клика и привяжите ее к команде ViewModel.

Поскольку одна из целей MVVM (которая является более распространенным шаблоном для Silverlight и WPF поверх MVC), заключается в разделении кода и пользовательского интерфейса. Поэтому, если вы возьмете первый подход, вы получите код в представлении. Если вы примете второй подход, вы можете отделить код от своего вида с помощью команд и привязок.

1

О каком контроллере вы говорите?

Концепция Commanding в Silverlight и WPF используется для объединения (в основном привязки) пользовательского интерфейса к бизнес-логике (будь то контроллер /viewmodel/model/etc ).

Это точка, чтобы переместить функциональность команды вне пользовательского интерфейса.

Пример. Сохранение виджета в вашем приложении, вероятно, всегда выполняется одинаково. Конечно, вы можете позволить пользователю изменить имя или что-то еще, но общее поведение всегда будет одинаковым. Теперь в вашем приложении вы можете инициировать сохранение виджета с помощью множества различных пользовательских интерфейсов, таких как страница с правой кнопкой мыши, которая сохраняет виджетов на этой странице, на странице 2 есть пункт меню, который сохраняет виджет на этой странице. Пользовательский интерфейс отличается, но поведение остается неизменным.

Вы можете достичь той же цели, используя управление событиями (например, захват события клика на кнопке), но теперь вы снова попадаете в контекст работы с конкретными проблемами пользовательского интерфейса. У командира, возможно, более чистое разделение.

Ещё вопросы

Сообщество Overcoder
Наверх
Меню