Энтони Гонсалвес - Изучаем Java EE 7

Валидация компонентов решает проблему дублирования кода и излишнего запутывания классов предметной модели. Разработчику достаточно написать ограничение всего один раз, использовать его и валидировать на любом уровне. Валидация компонентов позволяет реализовать ограничение в обычном коде Java, а потом определить его с помощью аннотации (метаданных). Затем вы можете использовать эту аннотацию в своем компоненте, свойствах, конструкторах, параметрах методов и с возвращаемым значением. Валидация компонентов предоставляет простой API, позволяющий разработчикам писать и переиспользовать ограничения, связанные с бизнес-логикой.

Из этой главы вы узнаете, почему валидация имеет принципиальное значение в приложении и почему ее необходимо дублировать на разных уровнях. Вы научитесь писать ограничения: от агрегирования уже имеющихся до разработки ваших собственных. Вы увидите, как применять такие ограничения в вашем приложении от уровня представления вплоть до уровня бизнес-модели. Затем вы научитесь валидировать эти ограничения (как внутри контейнера Java EE, так и вне его).

Большую часть рабочего времени программист тратит на то, чтобы гарантировать валидность (пригодность) тех данных, которые обрабатываются и сохраняются в приложении. Разработчик пишет ограничения для допустимых значений данных, применяет эти ограничения к логике и модели приложения, а также гарантирует, что на различных уровнях валидация этих ограничительных условий происходит согласованно. Таким образом, эти ограничения должны применяться в клиентском приложении (например, в браузере, если речь идет о разработке веб-приложения), на уровне представления, бизнес-логики, бизнес-модели (она же — предметная модель), в схеме базы данных и в определенной степени на уровне интероперабельности (рис. 3.1). Разумеется, для обеспечения согласованности необходимо синхронизировать эти правила на всех используемых уровнях и в применяемых технологиях.

Рис. 3.1.Валидация происходит сразу на нескольких уровнях

В неоднородных приложениях разработчику приходится иметь дело сразу с несколькими технологиями и языками. Поэтому даже простое правило валидации, например «этот элемент данных является обязательным и не может быть равен нулю», приходится по-разному выражать на Java, JavaScript, в схеме базы данных или в XML-схеме.

Независимо от того, создаете вы одноуровневое или многоуровневое приложение, вам так или иначе необходимо гарантировать, что обрабатываемые вашей программой данные корректны. Например, если адрес доставки или форма заказа товара не заполнены, вы не сможете отправить покупку клиенту. На Java вам то и дело приходится писать код, проверяющий правильность той или иной записи (if order.getDeliveryAddress() == null). Этот код может выдавать исключение или требовать участия пользователя для исправления внесенных данных. Валидация на уровне приложения обеспечивает довольно детализированный контроль, а также позволяет применять сравнительно сложные ограничения. (Является ли данная дата государственным праздником во Франции? Превышает ли общая среднегодовая сумма на счету клиента некоторое среднее значение?)

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

• Уровень представления.На этом уровне данные валидируются потому, что вы можете получать их от разных клиентов (браузер; инструмент для работы с командной строкой, например c URL, позволяющий отправлять команды по протоколу HTTP; нативное приложение). На этом же уровне вы стараетесь обеспечить быструю обратную связь с пользователем.

• Уровень бизнес-логики.Здесь координируются вызовы, направляемые к внутренним и внешним службам, к предметной модели, и так обеспечивается валидность обрабатываемых данных.

• Уровень бизнес-модели.Данный уровень обычно обеспечивает отображение предметной модели на базу данных, поэтому здесь валидация должна происходить до сохранения данных.

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

В конце концов, основная цель — хранить в вашей базе данных только валидную информацию, чтобы обработку можно было выполнить позднее. Строгие ограничения должны соблюдаться в реляционных базах данных, потому что здесь применяются схемы. Язык определения данных (DDL, также называемый языком описания данных) использует специальный синтаксис для определения и ограничения структур, входящих в состав базы данных. После этого вы сможете гарантировать, что данные в столбце не могут быть равны нулю (NOT NULL), должны быть целочисленными (INTEGER) или иметь ограничение максимальной длины (VARCHAR(20)). В последнем примере попытка вставить в столбец строку длиной 20 символов окончится неудачей.