WPF: Где останавливается MVVM и начинается выделение кода?

Question

Я создал окно, в котором есть ListView для отображения коллекции людей. Есть также 3 TextBox, которые должны отображать имя и фамилию человека, а также возраст. Наконец, есть Button для сохранения новых данных о людях, введенных в эти TextBox es.

Загрузка людей в ListView осуществляется с помощью MVVM. Работает как шарм! Кроме того, добавление новых людей в коллекцию путем нажатия Button также осуществляется через MVVM.

Но есть два варианта использования, в которых я не уверен, разумнее ли использовать команды, т. Е. MVVM, или просто простой код. Варианты использования:

1. Когда пользователь выбирает человека из ListView, TextBox es должен показать человека подробности.
2. Когда пользователь печатает символы вместо цифр в TextBox, который отображается возраст человека, его или его следует предупредить, что введенные данные неверны.

Причина, по которой я сомневаюсь, должен ли я использовать MVVM или выделенный код, заключается в том, что оба варианта использования относятся только к представлению (GUI), т. Е. Отсутствует интерактивность с моделью или бизнес-логикой приложения. Источник элемента ListView связан с набором лиц ObservableColleciton<Person>, и все данные, связанные с выбранным человеком, уже передаются в представление, когда ListView заполнено элементами. Во втором случае, опять же, нет необходимости переходить к ViewModel, чтобы позволить ему запустить окно сообщения о неправильном вводе пользователя. Как насчет создания обратного вызова проверки в age свойстве зависимостей класса ViewModel вместо этого?

Спасибо за все разъяснения.

Answer 1

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

Например, выПервая ситуация, как упомянуто выше, C.Лоуренс Уэнам , полностью разрешимый в коде XAML.Для достижения этого эффекта нет необходимости прибегать к программному обеспечению.И этот пример может быть расширен до взаимодействий с коллекцией, которая не обязательно представлена ​​в элементе управления, таком как список.Вы можете написать XAML-код, отвечающий на изменения в текущем элементе в коллекции в ViewModel с помощью привязки.

Ваша вторая ситуация также может быть достигнута с помощью средств проверки подлинности в ViewModel и привязки данных к этим средствам с помощью XAML.IDataErrorInfo - отличный механизм, который встроен именно для этой цели. Вот хорошая небольшая статья , демонстрирующая простое использование IDataErrorInfo.

Примеры того, когда вам приходится заходить в код, надеюсь, немногочисленны.Один пример, с которым я столкнулся, - это когда элемент управления не поддерживает ICommand, и вы не можете привязать функциональность к поведенческому элементу, примером элемента управления является ListBox.Но есть некоторые методы, чтобы обойти это ограничение, , как продемонстрировано в этом великом вопросе SO .Кроме того, в случае, если вам необходимо переопределить рендеринг в пользовательских элементах управления, вы должны будете сделать это в выделенном коде или в унаследованном классе.

Надеюсь, что это добавляет немного более полезной информации к ответам.

Answer 2

Текстовые поля могут и должны быть обязательно заполнены через привязки в XAML при изменении выбора ListView, например:

<ListView Name="people" .../>

<TextBox Text="{Binding ElementName=people, Path=SelectedItem.FirstName}"/>

Или чтобы уменьшить кодирование, поместите текстовые поля в их собственную панель с набором DataContext,Например:

<Grid DataContext="{Binding ElementName=people, Path=SelectedItem}">
    <TextBox Text="{Binding Path=FirstName}"/>
    <TextBox Text="{Binding Path=LastName}"/>
</Grid>

Проверка может быть подключена в XAML, но код, который выполняет проверку, обычно реализуется в классе.В System.Windows.Controls есть удобный абстрактный класс ValidationRule, который можно использовать для быстрого создания валидатора.См. этот блог для примера.

Answer 3

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

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

• Альтернатива(полусерьезный, но обычно эффективный) метод, чтобы решить, принадлежит ли что-то модели или viewModel, спрашивает себя, что произойдет, если вы передадите представление (Window, UserControl или что-то еще) своему графическому дизайнеру (даже если выесть один, притворись, что ты делаешь).Если вы согласны с мыслью, что он может поставить свои кодовые руки на c # -incompetent [*] (и сделать из этого беспорядок), это, как правило, признак того, что код строго связан с представлением и может безопасно жить вПосмотреть.В большинстве случаев вы заканчиваете тем, что переносите его в ViewModel.

[*] просто для образовательных целей многие дизайнеры более компетентны в c #, чем я: -)

Answer 4

Вы можете использовать правило проверки для своей привязки. Он не будет отображать окно сообщения (хотя это, вероятно, будет возможно), но вы можете определить ErrorTemplate, который показывает ошибку.