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

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

Понятие об ограничениях и валидации

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

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

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

Приложение

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

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

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

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

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

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

База данных

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

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

Клиент

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