Изучаем Java EE 7

Ограничение	Приемлемые типы	Описание
AssertFalse	Boolean	Аннотированный элемент должен возвращать значение true или false
AssertTrue
DecimalMax	BigDecimal, BigInteger, CharSequence, byte, short, int, long и соответствующие обертки	Элемент должен быть меньше или больше указанного значения
DecimalMin
Future	Calendar, Date	Аннотированный элемент должен быть датой в прошлом или будущем
Past
Max	BigDecimal, BigInteger, byte, short, int, long и их обертки	Элемент должен быть меньше или больше указанного значения
Min
Null	Object	Аннотированный элемент должен быть равен или не равен нулю
NotNull
Pattern	CharSequence	Элемент должен соответствовать указанному регулярному выражению
Digits	BigDecimal, BigInteger, CharSequence, byte, short, int, long и соответствующие обертки	Аннотированный элемент должен быть числом в допустимом диапазоне
Size	Object[], CharSequence, Collection, Map	Размер элемента должен укладываться в указанные границы

Определение собственных ограничений

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

Объединение ограничений

Удобный способ создания новых ограничений — агрегирование (объединение) уже имеющихся. В таком случае мы обходимся без класса реализации. Это совсем не сложно сделать, если имеющиеся ограничения обладают @Target(ElementType.ANNOTATION_TYPE), то есть при работе с ними одна аннотация может быть применена к другой. Такой подход называется «объединением ограничений» и позволяет создавать высокоуровневые ограничения.

В листинге 3.5 показано, как создать ограничение Email, обходясь лишь встроенными ограничениями из API валидации компонентов. Это ограничение гарантирует, что адрес электронной почты является ненулевым (@NotNull), состоит не менее чем из семи символов (@Size(min = 7)) и соответствует сложному регулярному выражению (@Pattern). В таком объединенном ограничении также должны определяться атрибуты message, groups и payload. Обратите внимание: класс реализации здесь отсутствует (validatedBy = {}).

Листинг 3.5. Ограничение для работы с электронной почтой, составленное из других ограничений

@NotNull

@Size(min = 7)

@Pattern(regexp = "[a-z0-9!#$%&'*+/=?^_`{|}~-]+ 

(?:\\.[a-z0-9!#$%&'*+/=?^_`{|}~-]+)*" 

········+ "@(?:[a-z0-9](?:[a-z0-9-]*[a-z0-9])?\\.)+[a-z0-9](?:[a-z0-9-]* 

········[a-z0-9])?")

@Constraint(validatedBy = {})

@Target({METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER})

@Retention(RetentionPolicy.RUNTIME)

public @interface Email {

··String message() default "Неверный электронный адрес";

··Class[] groups() default {};

··Class[] payload() default {};

}