В чем реальное преимущество сохранения кода вне кода XAML?

Question

В сообществе Silverlight предпринимается много усилий, чтобы сохранить код XAML в файле как можно свободнее от кода. Какова реальная мотивация этого?

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

<Button x:Name="SaveButton" Content="Save" Click="SaveButton_Click" />

...

private void SaveButton_Click(object sender, RoutedEventArgs e) {
    _myViewModel.SaveChanges();
}

Тогда почему это предпочтительнее?

<Button x:Name="SaveButton" Content="Save" Command="{Binding SaveCommand}" />

Где, очевидно, модель SaveCommand в моем представлении будет эффективно вызывать SaveChanges().

Это может привести к ситуациям, когда представление является 100% XAML, даже создание экземпляра модели представления в XAML, и соединения между представлением и моделью представления полностью выполняются посредством привязки. Конечно, это чисто, но что еще это? Гибкая? Зачем? представление все еще должно работать с правильным ViewModel, поэтому, если связь между ними существует и является неявной, почему бы не сделать ее более явной? Он также имеет недостаток потери поддержки времени компиляции. Если я подключу свою кнопку к обработчику событий, который не существует, компилятор скажет мне. Не будет, если я свяжусь с несуществующей командой.

Answer 1

В сообществе Silverlight предпринимается много усилий, чтобы сохранить код XAML в файле как можно свободнее от кода.Какова реальная мотивация этого?

Я бы сказал, что люди, которые хотят, чтобы код был «как можно более свободен от кода», - это те, кто запрыгнул на MVVM, не осознавая сути.(Либо это, либо вы неверно истолковали их точку зрения.)

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

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

Команда предлагает как минимум две возможности, которых нет у обработчика событий.Некоторые элементы управления WPF знают о свойстве CanExecute команды, поэтому, например, кнопка может быть отключена, когда команда недоступна для выполнения.Кроме того, конструктор и инфраструктура привязки поддерживают команды.

Если вы просто хотите вызвать метод при нажатии кнопки, то нет большое преимущество использования команд вместопросто вызов метода из обработчика событий.Так что не бойтесь использовать этот подход.(Третий подход, который предпочитает дизайнера программисту, заключается в использовании CallMethodAction из Blend 4).

Answer 2

Упрощает модульное тестирование и / или TDD.Используя MVVM и команды, я могу по существу построить свою модель представления и команды в стиле TDD и протестировать большую часть логики представления, фактически не имея представления XAML вообще.

Answer 3

Основное преимущество, которое я вижу с командой, - это когда у вас есть двойное требование выполнить действие и , подтверждающее, что действие может быть выполнено (т.е. контекст). Другими словами, если вы просто связываете щелчок с прямым вызовом метода, я согласен, я также не вижу никаких преимуществ. Однако, если щелчок должен быть обусловлен, а кнопка отключена в зависимости от контекста, привязка облегчает это через свойство CanExecute.

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

Answer 4

Вероятно, есть много аргументов, которые вы могли бы услышать, но, прагматически, есть только один, тестируемость . ViewModel мало что дает, если вы не создадите для него модульный тест, что, в свою очередь, означает, что вам нужно будет создать ViewModel таким образом, чтобы вы могли выполнить его модульное тестирование, используя такие методы, как внедрение зависимостей, IoC, бла, бла и т. Д. и т. д.

В результате модульные тесты могут охватывать большую часть кода ваших приложений, чем вы могли бы достичь, если бы код UI был более интегрированным.

Я не обязательно рекомендую это, чтобы сделать это должным образом, требуются значительные проектные усилия и продуманность. Следовательно, затраты на создание такого подхода довольно высоки, однако экономия за счет повышения качества может компенсировать эти затраты.