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

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

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

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

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

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

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

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

Валидация данных на стороне клиента очень важна: так пользователь сможет оперативно узнавать о том, что при вводе данных он допустил ошибку. Такая валидация сокращает количество избыточных обращений к серверу, практика использования также улучшается, поскольку многие ошибки отлавливаются на раннем этапе. Эта возможность особенно важна при разработке мобильных приложений, которые обычно должны обходиться очень узкой полосой доступа к сети.

Например, в типичном веб-приложении на уровне браузера применяется код JavaScript. Он обеспечивает простую валидацию данных в отдельных полях, а на уровне сервера проверяется соответствие более сложным бизнес-правилам. Нативные приложения, написанные на Java (Swing, мобильные приложения для Android), могут использовать весь потенциал этого языка при записи и валидации данных.

Зачастую корпоративные приложения должны обмениваться данными с внешними партнерами/системами. Такие приложения, относящиеся к категории «бизнес для бизнеса», получают информацию в любом формате, обрабатывают их, сохраняют и отправляют обратно партнеру. Валидация пользовательских (заказных) форматов — порой сложная и затратная задача. В настоящее время обмен данными между неоднородными системами обычно организуется на языке XML. Базы данных могут применять язык DDL для определения своей структуры. Аналогичным образом XML может использовать XSD (язык описания структуры XML-документа) для ограничения XML-документов. XSD выражает несколько правил, которым должен соответствовать XML-документ, чтобы удовлетворять выбранной схеме. Синтаксический разбор и валидация XML — распространенная задача, которая легко выполняется во многих фреймворках Java.

Как видите, валидация распределена по разным уровням приложения (от клиента до базы данных) и используется в разных технологиях (JavaScript, Java, DDL, XSD). Это означает, что разработчику приходится дублировать валидационный код на нескольких уровнях и писать его на разных языках. На такой распространенный подход тратится немало времени, он чреват ошибками, а в дальнейшем осложняется поддержка приложения. Кроме того, некоторые из подобных ограничений используются настолько часто, что их можно считать стандартами (проверка значения, его размера, диапазона). Было бы очень удобно централизовать эти ограничения в одном месте и совместно использовать их на разных уровнях. Вот здесь нам и пригодится валидация компонентов.

Валидация компонентов (Bean Validation) — это технология, ориентированная на Java, хотя и предпринимаются попытки интегрировать другие валидационные языки, в частности DDL или XSD. Валидация компонентов позволяет вам написать ограничение лишь однажды и использовать его на любом уровне приложения. Она не зависит от уровня, то есть одно и то же ограничение может использоваться повсюду, от уровня представления до уровня бизнес-модели. Валидация компонентов доступна как в серверных приложениях, так и в насыщенных графических клиентских интерфейсах, написанных на Java (Swing, Android). Такая валидация считается расширением объектной модели JavaBeans и, в принципе, может использоваться в качестве ядра других спецификаций (в этом вы убедитесь в следующих главах книги).

Валидация компонентов позволяет применять уже готовые, заранее определенные ограничения, а также писать собственные ограничения и также использовать их для валидации компонентов, атрибутов, конструкторов, возвращаемых типов методов и параметров. Этот API очень прост и при этом гибок, поскольку стимулирует вас определять собственные ограничения с применением аннотаций (как вариант — с использованием XML).

Разработчики занимаются ограничением и валидацией создаваемых моделей с тех пор, как существует язык Java. Код и фреймворки сначала были кустарными, они породили определенные практики, которые стали применяться в первых свободных проектах. Так, еще в 2000 году валидация пользовательского ввода стала использоваться в Struts — знаменитом MVC-фреймворке для Сети. Но прошло еще некоторое время, прежде чем появились целые валидационные фреймворки, предназначенные исключительно для работы с Java (а не просто для обеспечения веб-взаимодействий). Наиболее известными из таких фреймворков являются, пожалуй, Commons Validator из Apache Commons и Hibernate Validator. Другие подобные фреймворки — iScreen, OVal, а также распространенный фреймворк Spring, в котором содержится собственный валидационный пакет.