Независимо от того, создаете вы одноуровневое или многоуровневое приложение, вам так или иначе необходимо гарантировать, что обрабатываемые вашей программой данные корректны. Например, если адрес доставки или форма заказа товара не заполнены, вы не сможете отправить покупку клиенту. На Java вам то и дело приходится писать код, проверяющий правильность той или иной записи (if order.getDeliveryAddress() == null). Этот код может выдавать исключение или требовать участия пользователя для исправления внесенных данных. Валидация на уровне приложения обеспечивает довольно детализированный контроль, а также позволяет применять сравнительно сложные ограничения. (Является ли данная дата государственным праздником во Франции? Превышает ли общая среднегодовая сумма на счету клиента некоторое среднее значение?)
Валидация на уровне приложения, обеспечивающая правильность введенных данных, может проводиться в разных местах.
• Уровень представления. На этом уровне данные валидируются потому, что вы можете получать их от разных клиентов (браузер; инструмент для работы с командной строкой, например c URL, позволяющий отправлять команды по протоколу HTTP; нативное приложение). На этом же уровне вы стараетесь обеспечить быструю обратную связь с пользователем.
• Уровень бизнес-логики. Здесь координируются вызовы, направляемые к внутренним и внешним службам, к предметной модели, и так обеспечивается валидность обрабатываемых данных.
• Уровень бизнес-модели. Данный уровень обычно обеспечивает отображение предметной модели на базу данных, поэтому здесь валидация должна происходить до сохранения данных.
В сложном приложении зачастую приходится многократно реализовывать одно и то же ограничение сразу на нескольких уровнях, из-за чего значительная часть кода дублируется.
База данных
В конце концов, основная цель — хранить в вашей базе данных только валидную информацию, чтобы обработку можно было выполнить позднее. Строгие ограничения должны соблюдаться в реляционных базах данных, потому что здесь применяются схемы. Язык определения данных (DDL, также называемый языком описания данных) использует специальный синтаксис для определения и ограничения структур, входящих в состав базы данных. После этого вы сможете гарантировать, что данные в столбце не могут быть равны нулю (NOT NULL), должны быть целочисленными (INTEGER) или иметь ограничение максимальной длины (VARCHAR(20)). В последнем примере попытка вставить в столбец строку длиной 20 символов окончится неудачей.
Тем не менее выполнение валидации на уровне базы данных связано с некоторыми недостатками: негативное влияние на производительность, сообщения об ошибках выдаются вне контекста. Неверные данные должны пересечь все уровни приложения, прежде чем будут отправлены на удаленный сервер базы данных, который затем обработает валидацию и отправит обратно сообщение об ошибке. Ограничения, применяемые на уровне базы данных, учитывают только фактические данные, но не действия, осуществляемые пользователем. Поэтому сообщения об ошибках выдаются вне контекста и не могут точно описывать ситуацию. Именно по этой причине нужно стараться валидировать данные раньше — в приложении или еще на клиенте.
Клиент
Валидация данных на стороне клиента очень важна: так пользователь сможет оперативно узнавать о том, что при вводе данных он допустил ошибку. Такая валидация сокращает количество избыточных обращений к серверу, практика использования также улучшается, поскольку многие ошибки отлавливаются на раннем этапе. Эта возможность особенно важна при разработке мобильных приложений, которые обычно должны обходиться очень узкой полосой доступа к сети.
Например, в типичном веб-приложении на уровне браузера применяется код JavaScript. Он обеспечивает простую валидацию данных в отдельных полях, а на уровне сервера проверяется соответствие более сложным бизнес-правилам. Нативные приложения, написанные на Java (Swing, мобильные приложения для Android), могут использовать весь потенциал этого языка при записи и валидации данных.
Интероперабельность
Зачастую корпоративные приложения должны обмениваться данными с внешними партнерами/системами. Такие приложения, относящиеся к категории «бизнес для бизнеса», получают информацию в любом формате, обрабатывают их, сохраняют и отправляют обратно партнеру. Валидация пользовательских (заказных) форматов — порой сложная и затратная задача. В настоящее время обмен данными между неоднородными системами обычно организуется на языке XML. Базы данных могут применять язык DDL для определения своей структуры. Аналогичным образом XML может использовать XSD (язык описания структуры XML-документа) для ограничения XML-документов. XSD выражает несколько правил, которым должен соответствовать XML-документ, чтобы удовлетворять выбранной схеме. Синтаксический разбор и валидация XML — распространенная задача, которая легко выполняется во многих фреймворках Java.