Каково реальное преимущество сохранения кода из кода 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

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

Answer 2

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

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

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

Answer 3

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

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

Answer 4

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

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

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

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

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

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