Изучаем Java EE 7

Из этой главы вы узнали о различиях между объектом POJO, управляемым компонентом и компонентом CDI, а также о том, какие сервисы необходимо применять с каждой компонентной моделью. Благодаря спецификациям Managed Bean (запрос JSR 330) и CDI Bean (запрос JSR 299) в Java EE появилась стандартная, портируемая и типобезопасная поддержка для внедрения зависимостей. CDI предлагает дополнительные возможности, такие как области видимости и контексты, а также расширенные перехватчики, декораторы и события. В действительности CDI напрямую реализует несколько шаблонов проектирования, например «Мост» (с альтернативами), «Наблюдатель» (с событиями), «Декоратор», «Фабрика» (с производителями), и, конечно же, перехват и внедрение.

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

Будучи вертикальной спецификацией, CDI используется в других спецификациях Java EE. На самом деле в следующих главах этой книги так или иначе будут задействованы некоторые сервисы CDI.

Глава 3. Валидация компонентов

В предыдущей главе мы говорили о CDI, контексте и внедрении зависимостей, — центральной общей спецификации, действующей на всей платформе Java EE. Она помогает справляться с регулярно возникающими проблемами, связанными с внедрением, альтернативами, стереотипами, производителями данных. Разработчику приходится постоянно иметь дело с такими концепциями при решении рутинных задач. Еще одна распространенная задача, затрагивающая сразу несколько уровней современных приложений (или даже все уровни), — это валидация информации. Она выполняется повсюду, от уровня представления до базы данных. Поскольку обработка, хранение и получение валидных данных — это важнейшие задачи любого приложения, на каждом уровне правила валидации определяются по-своему. Но иногда на всех уровнях бывает реализована одна и та же логика валидации, из-за чего эта процедура становится длительной, сложной при поддержке, а также чреватой ошибками. Чтобы избежать дублирования правил валидации на каждом из уровней приложения, разработчики часто вплетают логику валидации непосредственно в предметную модель. В результате классы предметной модели оказываются переполнены валидационным кодом, который фактически представляет собой метаданные, описывающие сам класс.

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

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

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

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

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

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

Приложение