Итоговые сведения об уведомлениях и наблюдаемых моделях

Применение интерфейсов

в моделях и классов для списков улучшает пользовательский интерфейс приложения за счет поддержания его в синхронизированном состоянии с данными. В то время как ни один из интерфейсов не является сложным, они требуют обновлений кода. К счастью, в инфраструктуре предусмотрен класс , поддерживающий все необходимое для создания наблюдаемых коллекций. Также удачей следует считать обновление проекта Fody с целью автоматического добавления функциональности . При наличии под рукой упомянутых двух инструментов нет никаких причин отказываться от реализации наблюдаемых моделей в своих приложениях WPF.

Проверка достоверности WPF

Теперь, когда интерфейс

реализован и задействован класс , самое время заняться добавлением в приложение средств проверки достоверности. Приложениям необходимо проверять пользовательский ввод и обеспечивать обратную связь с пользователем, если введенные им данные оказываются некорректными. В настоящем разделе будут раскрыты наиболее распространенные механизмы проверки достоверности для современных приложений WPF, но это лишь часть возможностей, встроенных в инфраструктуру WPF.

Проверка достоверности происходит, когда привязка данных пытается обновить источник данных. В дополнение к встроенным проверкам, таким как исключения в блоках

для свойств, можно создавать специальные правила проверки достоверности. Если любое правило проверки достоверности (встроенное или специальное) нарушается, то в игру вступает класс , который обсуждается позже в главе.

На заметку! В каждом разделе главы можно продолжить работу с проектом из предыдущего раздела или создать копию проекта, специально предназначенную для нового раздела. Всем последующим разделам соответствуют отдельные проекты, которые доступны в каталоге с кодом для настоящей главы внутри хранилища GitHub.

Модификация примера для демонстрации проверки достоверности

В каталоге для этой главы внутри хранилища GitHub новый проект (скопированный из предыдущего примера) называется

. Если вы работаете с тем же самым проектом, созданным в предыдущем разделе, то при копировании в свой проект кода из примеров, приведенных в текущем разделе, просто должны обращать внимание на изменения пространств имен.

Класс Validation

Прежде чем добавлять проверку достоверности в проект, важно понять назначение класса

. Он входит в состав инфраструктуры проверки достоверности и предоставляет методы и присоединяемые свойства, которые могут применяться для отображения результатов проверки. При обработке ошибок проверки обычно используются три основных свойства класса , кратко описанные в табл. 28.2. Они будут применяться далее в разделе.

Варианты проверки достоверности

Как упоминалось ранее, технологии XAML поддерживают несколько механизмов для встраивания логики проверки достоверности внутрь приложения. В последующих разделах рассматриваются три самых распространенных варианта проверки.

Уведомление по исключениям

Хотя исключения не должны использоваться для обеспечения выполнения бизнес-логики, они могут (и будут) возникать, а потому требуют надлежащей обработки. Если исключения не обработаны в коде, тогда пользователь должен получить визуальную обратную связь об имеющейся проблеме. В отличие от Windows Forms в инфраструктуре WPF исключения привязки (по умолчанию) не распространяются до пользователя как собственно исключения. Тем не менее, они указываются визуально с применением декоратора (визуального уровня, который находится над элементами управления).

Запустите приложение, выберите запись в элементе

и очистите значение в текстовом поле . Поскольку свойство определено как имеющее тип (не тип , допускающий ), требуется числовое значение. После покидания поля по нажатию клавиши <ТаЬ> механизм привязки отправляет свойству пустую строку, но из-за того, что пустая строка не может быть преобразована в значение , внутри блока генерируется исключение. В нормальных обстоятельствах необработанное исключение привело бы к отображению окна сообщения пользователю, но в данном случае ничего подобного не происходит. Взглянув на порцию 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).

Прямоугольник красного цвета — это свойство

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

Интерфейс IDataErrorInfo

Интерфейс

предоставляет механизм для добавления специальной проверки достоверности в классы моделей. Данный интерфейс добавляется прямо в классы моделей (или моделей представлений), а код проверки помещается внутрь классов моделей (предпочтительно в частичные классы). Такой подход централизует код проверки достоверности в проекте, что совершенно не похоже на инфраструктуру Windows Forms, где проверка обычно делалась в самом пользовательском интерфейсе.