При изучении фреймворков MVC для flex, as3, silverlight и wpf... появляется общая концепция ICommand/commanding... Может ли кто-нибудь объяснить преимущество использования ICommand/Execute()?
Где я не вижу добавленную стоимость - Почему контроллер не может сопоставить ввод (т.е. событие click) с правильным методом внутри модели? Я предполагаю, что это потому, что командование покупает вам что-то - например, удаляет бизнес-логику из контроллера/потенциального обработчика событий в контроллере.
спасибо.
Здесь несколько случаев, которые демонстрируют команды значений, добавляют:
Подведение итогов
Команды обеспечивают четко определенный интерфейс между бизнес-логикой и презентацией. Разработчик бизнес-логики не заботится о том, как визуально будет выполняться определенное действие (например, команда). Он просто обеспечивает реализацию действия и возможность для презентации запрашивать состояние действия. Ему все равно, какой конкретный элемент (или элементы) пользовательского интерфейса инициирует это действие, как точно (в) способность выполнить это действие будет отражать в пользовательском интерфейсе, и какие изменения пользовательского интерфейса могут пройти в будущем. В то же время дизайнеру презентации не нужно ничего знать о обработчиках событий, контроллерах и т.д. У него есть команда, и он подключает его к любому элементу (или элементам) пользовательского интерфейса, который он выбирает, без необходимости вообще обращаться к С# -коду,
Простой ответ заключается в том, что команды являются связуемыми, а события - нет. Поэтому, если вы хотите ответить на событие нажатия кнопки, вы можете:
Поскольку одна из целей MVVM (которая является более распространенным шаблоном для Silverlight и WPF поверх MVC), заключается в разделении кода и пользовательского интерфейса. Поэтому, если вы возьмете первый подход, вы получите код в представлении. Если вы примете второй подход, вы можете отделить код от своего вида с помощью команд и привязок.
О каком контроллере вы говорите?
Концепция Commanding в Silverlight и WPF используется для объединения (в основном привязки) пользовательского интерфейса к бизнес-логике (будь то контроллер /viewmodel/model/etc ).
Это точка, чтобы переместить функциональность команды вне пользовательского интерфейса.
Пример. Сохранение виджета в вашем приложении, вероятно, всегда выполняется одинаково. Конечно, вы можете позволить пользователю изменить имя или что-то еще, но общее поведение всегда будет одинаковым. Теперь в вашем приложении вы можете инициировать сохранение виджета с помощью множества различных пользовательских интерфейсов, таких как страница с правой кнопкой мыши, которая сохраняет виджетов на этой странице, на странице 2 есть пункт меню, который сохраняет виджет на этой странице. Пользовательский интерфейс отличается, но поведение остается неизменным.
Вы можете достичь той же цели, используя управление событиями (например, захват события клика на кнопке), но теперь вы снова попадаете в контекст работы с конкретными проблемами пользовательского интерфейса. У командира, возможно, более чистое разделение.