До сих пор в примерах я показывал аннотированные атрибуты, но вместо этого можно аннотировать геттеры. Вы можете определять ограничения либо для атрибута, либо для геттера, но не для обоих одновременно. Лучше оставаться последовательным и всегда использовать аннотации либо только с атрибутами, либо только с геттерами.
Встроенные ограничения
Спецификация Bean Validation позволяет вам писать собственные ограничения и валидировать их. Но в ней присутствует и несколько встроенных ограничений. Мы уже сталкивались с некоторыми из них в предыдущих примерах, но в табл. 3.2 приведен исчерпывающий список всех встроенных ограничений (таких, которые уже готовы для использования в коде и не требуют разработки аннотации или класса реализации). Все встроенные ограничения определяются в пакете javax.validation.constraints.
Ограничение | Приемлемые типы | Описание |
---|---|---|
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 = {}).