Почему пользовательская команда и командный обработчик? - PullRequest
Новая
       41

Почему пользовательская команда и командный обработчик?

1 голос
/ 06 июня 2011

У меня есть форма с несколькими кнопками: добавить, изменить, удалить и т. Д. Я могу реализовать логику добавления, редактирования и удаления в add_click, edit_click, delete_click напрямую: обновлять данные в базе данных непосредственно в этих функциях. Я также могу использовать workItem.Commands[CommandNames.Add].Execute(); в add_click и обрабатывать в: 

    [CommandHandler(CommandNames.Add)]
    public void OnAdd(object sender, object target)

Какая польза от использования Microsoft.Practices.CompositeUI.Commands и CommandHandler? В каком случае я должен использовать это? Это реализация Microsoft общего шаблона команд? Спасибо!

1 Ответ

0 голосов
/ 16 января 2013

Я думаю, что я могу суммировать некоторые преимущества здесь, все они связаны с лучшим разделением проблем и кажутся понятными, особенно в MVVM-подобных сценариях.Просто чтобы быть ясным, вы можете делать то же самое, но я начал заставлять себя использовать Command, чтобы заставить себя писать «чистым» и «теоретически правильным» способом, чтобы привыкнуть к нему.

Это сказало:Разделение View и Code / Logic с помощью Command хорошо, потому что:

  • лучше для повторного использования: вы можете повторно использовать объект пользовательского интерфейса или командную логику, не задумываясь о другой части;в случае кнопки, вы в основном избегаете писать логику в самой кнопке, если вы измените жест с кнопки на (пример), вы вообще не будете касаться логики

  • этолучше для обслуживания: вы сосредотачиваетесь на аргументах события, когда пишете обработчик события, но когда вы переключаетесь на другой элемент управления или другое событие, вы могли бы стать очень зависимыми от аргументов события, например, потому что другой элемент управления / событие не поддерживает те же аргументы,Таким образом, код находится в одном месте и может быть легко передан (и поддержан), что заставляет разработчика писать лучший код.В случае общих групп разработчиков (это совет «на поле») легко, что каждый раз, когда разработчик добавляет несколько строк кода в обработчик событий, не возникает проблем с этим, если он работает, но если они должны редактировать общий блок командкода они должны делать это более ответственно.

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

Некоторые преимущества очевидны в средних и крупных проектахи со временем, но с подходом Command вы познакомитесь с шаблонами и более чистым стилем кодирования, вы привыкнете к более правильному способу разработки.

ДОПОЛНЕНИЕ: другие интересные моменты по поводу этого аргумента здесь

...