Каково реальное преимущество хранения кода из кода XAML позади?
Существует большое усилие в сообществе 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, поэтому если соединение между этими двумя существует и неявно, почему бы не сделать это более явным? Это также имеет недостаток потери поддержки времени компиляции. Если я сцеплю свою кнопку до обработчика событий, который не существует, то компилятор скажет мне. Это не будет, если я свяжу с несуществующей командой.
4 ответа
Это упрощает модульное тестирование и / или TDD. Используя MVVM и команды, я могу по существу построить свою модель представления и команды в стиле TDD и протестировать большую часть логики представления, фактически не имея представления XAML.
Возможно, вы услышите много аргументов в пользу этого, но с прагматической точки зрения есть только один - тестируемость. ViewModel мало что дает, если вы не создадите для нее модульный тест, что в свою очередь подразумевает, что вам нужно будет создать ViewModel таким образом, чтобы вы могли ее протестировать, используя такие техники, как внедрение зависимостей, IoC, бла-бла-бла и т.д. и т.п.
В результате модульные тесты могут покрыть большую часть кода вашего приложения, чем вы могли бы достичь, если бы сохранили код пользовательского интерфейса более интегрированным.
Я не обязательно рекомендую это, чтобы сделать это правильно, требуются значительные усилия по проектированию и продуманность. Поэтому затраты на создание такого подхода довольно высоки, однако экономия от повышения качества может вполне компенсировать эти затраты.
Основное преимущество команды я вижу в том, что у вас есть двойное требование - выполнить действие и проверить, что действие может быть выполнено (т.е. контекст). Другими словами, если вы просто связываете щелчок с прямым вызовом метода, я согласен, я тоже не вижу никаких преимуществ. Однако если щелчок должен быть обусловлен, а кнопка отключена на основе контекста, то привязка облегчает это через свойство CanExecute.
Таким образом, вместо того, чтобы беспокоиться об элементах управления в представлении (т.е. иметь логику, которая говорит "найдите этот элемент управления и установите его в состояние disabled, потому что мы не можем выполнить его прямо сейчас), мы можем создать команду и просто убедиться, что значение can execute возвращает false. Это можно тестировать независимо от представления, а когда вы сделаете привязку, сама привязка позаботится об управлении включенным свойством элемента управления.
В разработке Сообщество Silverlight для хранения XAML код за файлом как свободный от кода, как возможный. Какая настоящая мотивация
Я бы сказал, что люди, которые хотят, чтобы код был «как можно более свободным от кода», - это те, кто вскочил на подножку MVVM, не поняв сути. (Либо так, либо вы неверно истолковали их точку зрения).
Смысл не в том, чтобы не содержать кода программной части, а в том, чтобы убедиться, что View отвечает только за визуальное представление. Тот факт, что многие визуальные аспекты могут быть определены декларативно, означает, что в коде программной части меньше кода, но это не означает, что вы должны не спешить писать код программной части там, где, по вашему мнению, это необходимо, и не выходить за рамки ответственности представления.
в чем преимущество использования команда вместо обработчика событий?
Команда предлагает по крайней мере две возможности, которых нет у обработчика событий. Некоторые элементы управления WPF знают о свойстве CanExecute команды, поэтому, например, кнопка может быть отключена, когда команда недоступна для выполнения. Также конструктор и структура привязки осведомлены о командах.
Если вы просто хотите вызвать метод при нажатии кнопки, нет большого преимущества в использовании команд вместо простого вызова метода из обработчика событий. Так что не бойтесь использовать этот подход. (Третий подход, который предпочитает дизайнера программисту, - использовать CallMethodAction из Blend 4).