Обработка валидации данных в слое VM (MVVM)

Доброго дня всем.

Понимаю, что тема избита, но так как я только изучаю WPF и его применение в паттерне MVVM, прошу сильно не пинать.
В целом задача простая, но как сделать правильно не понимаю. Итак, есть простая модель данных
Есть VM, которая получает и загружает эту модель в своё свойство, которое привязывается к View. Отмечу, что INPC реализован, но для примера не показан.
Также в VM есть команда, которая берёт значение Interval и пуляет его куда следует.
И собственно сам вопрос: правильно ли будет реализовать в модели IDataErrorInfo, чтобы в VM можно было обрабатывать исключения/ошибки валидации модели и поднимать свойства наличия ошибки в VM, чтобы в команде VM можно было посмотреть на эти свойства?

0

Uswer, стандартный HasError можно прокинуть в VM, но зачем!? Если сама View уже знает, что данные введены не верно и не дает нажать на кнопку!
Далее, эта же кнопка может блокироваться от других, уже своих свойств MyHasError...
Это поведение тоже можно изменить и не блокировать кнопку, но опять же - зачем? Пользователь будет давить на нее до посинения и не понимать что происходит.

В конце концов, в случае стандартной ошибки можно вывести юзеру сообщение в этом же окне о причине ошибки. Без VM вообще, а через триггеры View..

0

Сообщение от Uswer То есть либо кнопка доступна и команда вызывается, либо кнопка блокируется.

Так как Enabled кнопки зависит не только от команды из VM, но и от некоторых параметров View, то лично я бы ввёл в View дополнительную внутреннюю зависимость:

Можно вместо конвертера использовать триггера в стиле, но на мой взгляд это менее удобно.

Сообщение от Uswer Вариант! Но неужели никак нельзя оповестить VM иначе?

Можно.
Validation.HasError - это свойство "только для чтения".
Для его привязки (передачи в источник) нужно использовать какие-то дополнительные механизмы.
Один из них: Behavior для привязки свойств только для чтения [WPF, Элд Хасп]

Добавлено через 13 минут

Сообщение от Uswer Правда это только в случае MVVM, под который WPF заточена

Исторически наоборот.
WPF - это развитие от устаревших Forms. Те же привязки появились в Формах.
При создании WPF пришло понимание, что основным способом задания значений в View должны стать именно привязки. Для привязок требуются объекты-источники со свойствами-источниками.
Самые распространённые на тот момент паттерны MVC и MVP плохо подходили под такую архитектуру. Поэтому часть команды разработчиков WPF дополнила семейство MV* новым паттерном MVVM, который учитывал особенности WPF.

Если бы вы разрабатывали Форм приложения в архитектуре MVP с использованием привязок, то при переходе на WPF+MVVM вы только почувствовали бы "насколько проще жить стало!". Основная проблема при переходе с Форм на WPF - это то что 99% разработчиков в Формах устраивают свалку кода без всякой оглядки на архитектурные паттерны. И само по себе требование соблюдать правильную архитектуру (по любому паттерну) уже ставит их в ступор.

Попробуйте, как вы привыкли создать WPF приложение с Code Behind и использованием Привязок хотя бы в паттерне MVP. И сами увидите, насколько это сложнее чем MVVM.

0

Ниже оффтоп, однако мне хочется услышать мнение профи.

В формах, если применять MVP или без него, основной механизм взаимодействия слоёв событийный.
Теперь смотрим на WPF. События также поддерживаются, но их обработка крайне не рекомендуется при разработке по MVVM. При этом сам XAML внутри построен на тех же событиях, как минимум механизм привязки только на них и держится. Однако тут уже появляются Команды. Команды также не мыслимы без событий, т.к. даже интерфейс ICommand предполагает наличие события.

Если вспомнить что же такое События, то это удобная обёртка над делегатами. Спрашивается, зачем вводить ещё одну конструкцию в виде команд, если есть хорошо понятные события? В чём профит?

	Комментарий модератора
	Ответы на этот вопрос перенесены в тему: Зачем вводить ещё одну конструкцию в виде команд, если есть хорошо понятные события? В чём профит?

0