Изучаем Java EE 7

В листинге 3.19 показан дескриптор развертывания validation.xml, имеющий корневой XML-элемент validation-config. Гораздо важнее, что здесь определяется внешний файл для отображения ограничений: constraints.xml (показан в листинге 3.20).

Листинг 3.19. Файл validation.xml, в котором определяется файл для отображения ограничений

····xmlns="http://jboss.org/xml/ns/javax/validation/configuration"

····xmlns: xsi="http://www.w3.org/2001/XMLSchema-instance"

····xsi: schemaLocation="http://jboss.org/xml/ns/javax/validation/configuration 

·························validation-configuration-1.1.xsd"

····version="1.1">

··META-INF/constraints.xml

Листинг 3.20. Файл, в котором определяются ограничения для компонента

····xmlns="http://jboss.org/xml/ns/javax/validation/mapping"

····xmlns: xsi="http://www.w3.org/2001/XMLSchema-instance"

····xsi: schemaLocation="http://jboss.org/xml/ns/javax/validation/mapping 

·························validation-mapping-1.1.xsd"

····version="1.1">

··

····

······

········Title should not be null

······

····

····

······

······

········2

······

····

····

······

········2000

······

····

··

Файл constraints.xml из листинга 3.20 определяет метаданные для объявления ограничений, используемых с классом Book. Сначала он применяет ограничение @NotNull к атрибуту title и заново задает выводимое по умолчанию сообщение об ошибке («Название не может быть пустым»). К атрибуту price применяются два разных ограничения, его минимальное значение равно 2. Ситуация напоминает код из листинга 3.1, где метаданные определялись с помощью аннотаций.

Валидация ограничений

До сих пор мы плотно работали с ограничениями — определяли их, агрегировали, реализовывали наши собственные, настраивали сообщения об ошибках, возились с группами. Но без специальной валидационной среды исполнения проверка ограничений невозможна. Как и с большинством технологий Java EE 7, код в данном случае должен работать внутри контейнера или управляться поставщиком.

Ограничения можно применять к компонентам, атрибутам, геттерам, конструкторам, параметрам методов и возвращаемым значениям. Итак, валидация может выполняться для элементов всех этих типов. Можно валидировать компоненты, свойства, значения, методы и группы, а также задавать собственные ограничения для графа объектов. Чтобы все эти ограничения проверялись во время исполнения, вам потребуется валидационный API.

Валидационные API

Среда исполнения валидации использует небольшой набор API, которые позволяют ей проверять ограничения. Основной API — это интерфейс javax.validation.Validator. Он содержит соглашения для валидации объектов и графов объектов независимо от уровня, на котором этот интерфейс реализован (уровень представления, уровень бизнес-логики или бизнес-модели). При ошибке валидации возвращается набор интерфейсов javax.validation.ConstraintViolation. Он предоставляет контекст произошедшего нарушения, а также сообщение, описывающее нарушение.

Валидатор

Основной входной точкой для валидации является интерфейс Validator. Этот API позволяет проверять экземпляры компонентов, обходясь немногочисленными методами, перечисленными в табл. 3.4. Все эти методы объявляют каждое новое ограничение по одному и тому же образцу.

1. Устанавливается подходящая реализация ConstraintValidator, которая будет использоваться при определении данного ограничения (например, определяется ConstraintValidator для ограничения @Size, применяемого со строкой).

2. Выполняется метод isValid.

3. Если isValid возвращает true, программа переходит к следующему ограничению.

4. Если isValid возвращает false, поставщик валидации компонентов добавляет ConstraintViolation в список нарушений ограничений.

Таблица 3.4. Методы интерфейса Validator