Итоговые сведения об уведомлениях и наблюдаемых моделях
Применение интерфейсов INotifyPropertyChanged в моделях и классов ObservableCollection для списков улучшает пользовательский интерфейс приложения за счет поддержания его в синхронизированном состоянии с данными. В то время как ни один из интерфейсов не является сложным, они требуют обновлений кода. К счастью, в инфраструктуре предусмотрен класс ObservableCollection, поддерживающий все необходимое для создания наблюдаемых коллекций. Также удачей следует считать обновление проекта Fody с целью автоматического добавления функциональности INotifyPropertyChanged. При наличии под рукой упомянутых двух инструментов нет никаких причин отказываться от реализации наблюдаемых моделей в своих приложениях WPF.
Проверка достоверности WPF
Теперь, когда интерфейс INotifyPropertyChanged реализован и задействован класс ObservableCollection, самое время заняться добавлением в приложение средств проверки достоверности. Приложениям необходимо проверять пользовательский ввод и обеспечивать обратную связь с пользователем, если введенные им данные оказываются некорректными. В настоящем разделе будут раскрыты наиболее распространенные механизмы проверки достоверности для современных приложений WPF, но это лишь часть возможностей, встроенных в инфраструктуру WPF.
Проверка достоверности происходит, когда привязка данных пытается обновить источник данных. В дополнение к встроенным проверкам, таким как исключения в блоках set для свойств, можно создавать специальные правила проверки достоверности. Если любое правило проверки достоверности (встроенное или специальное) нарушается, то в игру вступает класс Validation, который обсуждается позже в главе.
На заметку! В каждом разделе главы можно продолжить работу с проектом из предыдущего раздела или создать копию проекта, специально предназначенную для нового раздела. Всем последующим разделам соответствуют отдельные проекты, которые доступны в каталоге с кодом для настоящей главы внутри хранилища GitHub.
Модификация примера для демонстрации проверки достоверности
В каталоге для этой главы внутри хранилища GitHub новый проект (скопированный из предыдущего примера) называется WpfValidations. Если вы работаете с тем же самым проектом, созданным в предыдущем разделе, то при копировании в свой проект кода из примеров, приведенных в текущем разделе, просто должны обращать внимание на изменения пространств имен.
Класс Validation
Прежде чем добавлять проверку достоверности в проект, важно понять назначение класса Validation. Он входит в состав инфраструктуры проверки достоверности и предоставляет методы и присоединяемые свойства, которые могут применяться для отображения результатов проверки. При обработке ошибок проверки обычно используются три основных свойства класса Validation, кратко описанные в табл. 28.2. Они будут применяться далее в разделе.
![]()
Варианты проверки достоверности
Как упоминалось ранее, технологии XAML поддерживают несколько механизмов для встраивания логики проверки достоверности внутрь приложения. В последующих разделах рассматриваются три самых распространенных варианта проверки.
(window.adrunTag = window.adrunTag || []).push({v: 1, el: 'adrun-4-390', c: 4, b: 390})
Уведомление по исключениям
Хотя исключения не должны использоваться для обеспечения выполнения бизнес-логики, они могут (и будут) возникать, а потому требуют надлежащей обработки. Если исключения не обработаны в коде, тогда пользователь должен получить визуальную обратную связь об имеющейся проблеме. В отличие от 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, где проверка обычно делалась в самом пользовательском интерфейсе.
