Изучаем Java EE 7 - [38]
>··}
>··public @NotNull Double calculateTotalAmount(@GreaterThanZero Double changeRate) {
>····//…
>··}
>··// Геттеры и сеттеры
>}
В листинге 3.4 @ChronologicalDates — это ограничение, действующее на уровне класса и основанное на нескольких свойствах класса Order (в данном случае оно гарантирует, что значения creationDate, paymentDate и deliveryDate являются хронологическими). Атрибут orderId имеет два ограничения: он не может быть равен нулю (@NotNull) и должен соответствовать шаблону регулярного выражения (@Pattern). Конструктор Order гарантирует, что параметр creationDate должен обозначать момент в прошлом. Метод calculateTotalAmount (рассчитывающий общую сумму заказа на покупку) проверяет, является ли changeRate значением больше нуля — @GreaterThanZero, а также гарантирует, что возвращаемая сумма будет ненулевой.
До сих пор в примерах я показывал аннотированные атрибуты, но вместо этого можно аннотировать геттеры. Вы можете определять ограничения либо для атрибута, либо для геттера, но не для обоих одновременно. Лучше оставаться последовательным и всегда использовать аннотации либо только с атрибутами, либо только с геттерами.
Встроенные ограничения
Спецификация 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 = {}).
>@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 {};
>}
Все встроенные ограничения (@NotNull, @Size и @Pattern) уже имеют собственные сообщения об ошибках (элемент message()). Таким образом, если у вас окажется нулевой адрес электронной почты, то по результатам валидации ограничение, приведенное в листинге 3.5, выдаст сообщение об ошибке @NotNull, а не то, что вы определили (Неверный электронный адрес). Возможно, вы захотите использовать для всех ограничений Email одно общее сообщение об ошибке, а не несколько разных. Для этого можно добавить аннотацию @ReportAsSingleViolation (как будет показано ниже, в листинге 3.24). Если вы так поступите, то валидация составного ограничения прекратится после невыполнения первого же из входящих в него ограничений и будет выдано сообщение об ошибке, соответствующее именно тому ограничению, которое оказалось невыполненным.
