Изучаем Java EE 7 - [39]

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

Примечание

Создавая новое ограничение, обязательно дайте ему информативное имя. Если название для аннотации будет подобрано правильно, то ограничения будут лучше восприниматься в коде.

Обобщенное ограничение

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

В листинге 3.6 показан объект POJO, представляющий сетевое соединение с сервером, на котором находятся элементы CD-BookStore. Этот POJO имеет несколько атрибутов типа String, все они представляют URL. Вы хотите, чтобы URL имел допустимый формат, и даже задаете конкретный протокол (например, http, ftp…), хост и/или номер порта. Пользовательское ограничение @URL гарантирует, что разные строковые атрибуты класса ItemServerConnection соответствуют формату URL. Например, атрибут resourceURL может представлять собой любой допустимый URL (в частности, file://www.cdbookstore.com/item/123). С другой стороны, вы хотите ограничить атрибут itemURL так, чтобы он работал только с http-протоколом и с хостом, имя которого начинается с www.cdbookstore.com (например, http://www.cdbookstore.com/book/h2g2).

Листинг 3.6. Ограничивающая аннотация для работы с URL, используемая с несколькими атрибутами

public class ItemServerConnection {
··@URL
··private String resourceURL;
··@NotNull @URL(protocol = "http", host = "www.cdbookstore.com")
··private String itemURL;
··@URL(protocol = "ftp", port = 21)
··private String ftpServerURL;
··private Date lastConnectionDate;
··// Конструкторы, геттеры, сеттеры
}

Если мы хотим создать такое пользовательское ограничение для работы с URL, то первым делом должны определить аннотацию. В листинге 3.7 показана аннотация, выполняющая все предпосылки для валидации компонентов (метааннотация @Constraint, атрибуты message, groups и payload). Кроме того, она добавляет и специфические атрибуты: protocol, host и port, которые отображаются на имена элементов аннотации (например, @URL(protocol = "http")). Ограничение может использовать любой атрибут любого типа данных. Обратите также внимание, что у этих атрибутов есть значения, задаваемые по умолчанию, — например, пустая строка для протокола или хоста или –1 для номера порта.

Листинг 3.7. Ограничивающая аннотация для работы с URL

@Constraint(validatedBy = {URLValidator.class})
@Target({METHOD, FIELD, ANNOTATION_TYPE, CONSTRUCTOR, PARAMETER})
@Retention(RUNTIME)
public @interface URL {
··String message() default "Malformed URL";
··Class[] groups() default {};
··Class[] payload() default {};
··String protocol() default "";
··String host() default "";
··int port() default -1;
}

В листинге 3.7 мы могли бы агрегировать уже имеющиеся ограничения, например @NotNull. Но основное различие между объединением ограничений и созданием обобщенного ограничения заключается в применении класса реализации, объявляемого в атрибуте validatedBy (здесь он ссылается на класс URLValidator.class).

В листинге 3.8 показан класс реализации URLValidator. Как видите, он реализует интерфейс ConstraintValidator и, следовательно, методы initialize и isValid. Здесь важно отметить, что класс URLValidator имеет три атрибута, определенные в аннотации (protocol, host и port), и инициализирует их в методе initialize(URL url). Этот метод вызывается на этапе инстанцирования валидатора. В качестве параметра он получает ограничивающую аннотацию (здесь URL), поэтому может извлекать значения и использовать их при валидации. Так можно поступить с атрибутом itemURL protocol, который в листинге 3.6 имеет строковое значение "http".

Листинг 3.8. Реализация ограничения для работы с URL

public class URLValidator implements ConstraintValidator {
··private String protocol;
··private String host;
··private int port;
··public void initialize(URL url) {
····this.protocol = url.protocol();
····this.host = url.host();
····this.port = url.port();
··}
··public boolean isValid(String value, ConstraintValidatorContext context) {
····if (value == null || value.length() == 0) {
····return true;
··}
··java.net.URL url;
··try {
····// Преобразуем URL в java.net.URL для проверки того,
····// имеет ли URL допустимый формат
····url = new java.net.URL(value);
··} catch (MalformedURLException e) {
····return false;
··}
··// Проверяет, имеет ли атрибут протокола допустимое значение
··if (protocol!= null && protocol.length() > 0 &&

!url.getProtocol(). equals(protocol)) {
····return false;
··}
··if (host!= null && host.length() > 0 &&!url.getHost(). startsWith(host)) {
····return false;
··}
··if (port!= -1 && url.getPort()!= port) {