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

····weld.shutdown();

··}

}

Интеграционный тест BookServiceIT в листинге 2.54 требует, чтобы был активизирован MockGenerator. Для этого необходимо выделить отдельный файл beans.xml для тестирования (листинг 2.55) и активизации альтернатив (с тегом ). Если вы захотите увеличить объем журналов в тестовой среде, можете активизировать LoggingInterceptor в файле beans.xml.

·······xmlns: xsi="http://www.w3.org/2001/XMLSchema-instance"

·······xsi: schemaLocation="http://xmlns.jcp.org/xml/ns/javaee

·······http://xmlns.jcp.org/xml/ns/javaee/beans_1_1.xsd"

·······version="1.1" bean-discovery-mode="all">

··

····org.agoncal.book.javaee7.chapter02.MockGenerator

··

··

····org.agoncal.book.javaee7.chapter02.LoggingInterceptor

··

Для выполнения интеграционного теста с помощью плагина Maven Failsafe (определенного в pom.xml в листинге 2.53) введите следующую команду Maven:

$ mvn integration-test

Класс BookServiceIT должен выполнить один успешный интеграционный тест. Вы также увидите несколько протоколов или регистраций входа в метод и выхода из него.

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

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

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

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

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

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

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

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

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

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