Итоговые сведения об уведомлениях и наблюдаемых моделях
Применение интерфейсов
INotifyPropertyChanged
в моделях и классов
ObservableCollection
для списков улучшает пользовательский интерфейс приложения за счет поддержания его в синхронизированном состоянии с данными. В то время как ни один из интерфейсов не является сложным, они требуют обновлений кода. К счастью, в инфраструктуре предусмотрен класс
ObservableCollection
, поддерживающий все необходимое для создания наблюдаемых коллекций. Также удачей следует считать обновление проекта Fody с целью автоматического добавления функциональности
INotifyPropertyChanged
. При наличии под рукой упомянутых двух инструментов нет никаких причин отказываться от реализации наблюдаемых моделей в своих приложениях WPF.
Проверка достоверности WPF
Теперь, когда интерфейс
INotifyPropertyChanged
реализован и задействован класс
ObservableCollection
, самое время заняться добавлением в приложение средств проверки достоверности. Приложениям необходимо проверять пользовательский ввод и обеспечивать обратную связь с пользователем, если введенные им данные оказываются некорректными. В настоящем разделе будут раскрыты наиболее распространенные механизмы проверки достоверности для современных приложений WPF, но это лишь часть возможностей, встроенных в инфраструктуру WPF.
Проверка достоверности происходит, когда привязка данных пытается обновить источник данных. В дополнение к встроенным проверкам, таким как исключения в блоках
set
для свойств, можно создавать специальные правила проверки достоверности. Если
любое правило проверки достоверности (встроенное или специальное) нарушается, то в игру вступает класс
Validation
, который обсуждается позже в главе.
На заметку! В каждом разделе главы можно продолжить работу с проектом из предыдущего раздела или создать копию проекта, специально предназначенную для нового раздела. Всем последующим разделам соответствуют отдельные проекты, которые доступны в каталоге с кодом для настоящей главы внутри хранилища GitHub.
Модификация примера для демонстрации проверки достоверности
В каталоге для этой главы внутри хранилища GitHub новый проект (скопированный из предыдущего примера) называется
WpfValidations
. Если вы работаете с тем же самым проектом, созданным в предыдущем разделе, то при копировании в свой проект кода из примеров, приведенных в текущем разделе, просто должны обращать внимание на изменения пространств имен.
Класс Validation
Прежде чем добавлять проверку достоверности в проект, важно понять назначение класса
Validation
. Он входит в состав инфраструктуры проверки достоверности и предоставляет методы и присоединяемые свойства, которые могут применяться для отображения результатов проверки. При обработке ошибок проверки обычно используются три основных свойства класса
Validation
, кратко описанные в табл. 28.2. Они будут применяться далее в разделе.
Варианты проверки достоверности
Как упоминалось ранее, технологии XAML поддерживают несколько механизмов для встраивания логики проверки достоверности внутрь приложения. В последующих разделах рассматриваются три самых распространенных варианта проверки.
Уведомление по исключениям
Хотя исключения не должны использоваться для обеспечения выполнения бизнес-логики, они могут (и будут) возникать, а потому требуют надлежащей обработки. Если исключения не обработаны в коде, тогда пользователь должен получить визуальную обратную связь об имеющейся проблеме. В отличие от Windows Forms в инфраструктуре WPF исключения привязки (по умолчанию) не распространяются до пользователя как собственно исключения. Тем не менее, они указываются визуально с применением декоратора (визуального уровня, который находится над элементами управления).
Запустите приложение, выберите запись в элементе
ComboВох
и очистите значение в текстовом поле
Id
. Поскольку свойство
Id
определено как имеющее тип
int
(не тип
int
, допускающий
null
), требуется числовое значение. После покидания поля
Id
по нажатию клавиши <
ТаЬ> механизм привязки отправляет свойству
CarId
пустую строку, но из-за того, что пустая строка не может быть преобразована в значение
int
, внутри блока
set
генерируется исключение. В нормальных обстоятельствах необработанное исключение привело бы к отображению окна сообщения пользователю, но в данном случае ничего подобного не происходит. Взглянув на порцию
Debug (Отладка) окна
Output (Вывод), вы заметите следующие строки:
System.Windows.Data Error: 7 : ConvertBack cannot convert value '' (type 'String').
BindingExpression:Path=Id; DataItem='Car' (HashCode=52579650); target element is
'TextBox' (Name=''); target property is 'Text' (type 'String') FormatException:'System.
FormatException: Input string was not in a correct format.
Ошибка System.Windows.Data: 7 : ConvertBack не может преобразовать (типа String).
BindingExpression : Path=Id; DataItem='Car' (HashCode=52579650);
целевой элемент - TextBox (Name=''); целевое свойство - Text
(типа String) FormatExceptionSystem.FormatException:
Входная строка не имела корректный формат.
Визуально исключение представляется с помощью тонкого прямоугольника красного цвета вокруг элемента управления (рис. 28.2).
Прямоугольник красного цвета — это свойство
ErrorTemplate
объекта
Validation
, которое действует в качестве декоратора для связанного элемента управления. Несмотря на то что стандартный внешний вид говорит о наличии ошибки, нет никакого указания на то, что именно пошло не так. Хорошая новость в том, что шаблон отображения ошибки в свойстве
ErrorTemplate
является полностью настраиваемым, как вы увидите позже в главе.
Интерфейс IDataErrorInfo
Интерфейс
IDataErrorInfo
предоставляет механизм для добавления специальной проверки достоверности в классы моделей. Данный интерфейс добавляется прямо в классы моделей (или моделей представлений), а код проверки помещается внутрь классов моделей (предпочтительно в частичные классы). Такой подход централизует код проверки достоверности в проекте, что совершенно не похоже на инфраструктуру Windows Forms, где проверка обычно делалась в самом пользовательском интерфейсе.
