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

• придать платформе большую целостность;

• соединить веб-уровень и уровень транзакций;

• сделать внедрение зависимостей полноправным компонентом платформы;

• иметь возможность легко добавлять новые расширения.

Сегодня, с появлением Java EE 7, CDI 1.1 становится основанием для многих запросов JSR, и здесь уже появились определенные улучшения.

Что нового в CDI 1.1

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

• новый класс CDI обеспечивает программный доступ к средствам CDI извне управляемого компонента;

• перехватчики, декораторы и альтернативы могут быть приоритизированы (@Priority) и упорядочены для всего приложения;

• при добавлении аннотации @Vetoed к любому типу или пакету CDI перестает считать данный тип или пакет своим компонентом;

• квалификатор @New в CDI 1.1 считается устаревшим, и сегодня приложениям предлагается вместо этого внедрять ограниченные компоненты @Dependent;

• новая аннотация @WithAnnotations позволяет расширению фильтровать, какие типы оно будет видеть.

В табл. 2.1 перечисляются основные пакеты, относящиеся к CDI. Вы найдете аннотации и классы CDI в пакетах javax.enterprise.inject и javax.decorator.

Таблица 2.1. Основные пакеты, относящиеся к CDI

Пакет	Описание
javax.inject	Содержит базовую спецификацию по внедрению зависимостей для Java API (запрос JSR 330)
javax.enterprise.inject	Основные API для внедрения зависимостей
javax.enterprise.context	Области видимости CDI и контекстуальные API
javax.enterprise.event	События CDI и API алгоритмов наблюдения
javax.enterprise.util	Пакет утилит CDI
javax.interceptor	Содержит API перехватчика (запрос JSR 318)
javax.decorator	API декоратора CDI

Базовая реализация

Базовой реализацией CDI является Weld, свободный проект от JBoss. Есть и другие реализации, такие как Apache OpenWebBeans или CanDi (от Caucho). Важно также упомянуть проект Apache DeltaSpike, который ссылается на набор портируемых расширений CDI.

Создание компонента CDI

Компонентом CDI может быть тип любого класса, содержащий бизнес-логику. Он может вызываться напрямую из Java-кода посредством внедрения либо с помощью языка выражений (EL) со страницы JSF. Как показано в листинге 2.1, компонент — это объект POJO, который не наследует от других объектов и не расширяет их, может внедрять ссылки на другие компоненты (@Inject) и имеет свой жизненный цикл, управляемый контейнером (@PostConstruct). Вызовы метода, выполняемые таким компонентом, могут перехватываться (здесь @Transactional основана на перехватчике и далее описана подробнее).

Листинг 2.1. Компонент BookService, использующий внедрение, управление жизненным циклом и перехват

public class BookService {
@Inject
private NumberGenerator numberGenerator;
··@Inject
··private EntityManager em;
··private Date instanciationDate;
··@PostConstruct
··private void initDate() {
····instanciationDate = new Date();
··}
··@Transactional
··public Book createBook(String title, Float price, String description) {
····Book book = new Book(title, price, description);
····book.setIsbn(numberGenerator.generateNumber());
····book.setInstanciationDate(instanciationDate);
····em.persist(book);
····return book;
··}
}

Внутренняя организация компонента CDI

В соответствии со спецификацией CDI 1.1 контейнер распознает как компонент CDI любой класс, если:

• он не относится к нестатичным внутренним классам;

• это конкретный класс либо класс, имеющий аннотацию @Decorator;

• он имеет задаваемый по умолчанию конструктор без параметров либо объявляет конструктор с аннотацией @Inject.

Компонент может иметь опциональную область видимости, опциональное EL-имя (EL — язык выражений), набор связок с перехватчиком и опциональное управление жизненным циклом.

Внедрение зависимостей

Java относится к объектно-ориентированным языкам программирования. Это означает, что реальный мир отображается с помощью объектов. Класс Book отображает копию H2G2, Customer замещает вас, а PurchaseOrder замещает то, как вы покупаете эту книгу. Эти объекты зависят друг от друга: книга может быть прочитана покупателем, а заказ на покупку может относиться к нескольким книгам. Такая зависимость — одно из достоинств объектно-ориентированного программирования.

Например, процесс создания книги (BookService) можно сократить до инстанцирования объекта Book, сгенерировав уникальный номер с использованием другого сервиса (NumberGenerator), сохраняющий книгу в базу данных. Сервис NumberGenerator может сгенерировать номер ISBN из 13 цифр либо ISBN более старого формата из восьми цифр, известный как ISSN. BookService затем будет зависеть от IsbnGenerator либо IssnGenerator. Тот или иной вариант определяется условиями работы или программным окружением.

Рисунок 2.3 демонстрирует схему класса интерфейса NumberGenerator, который имеет один метод (String generateNumber()) и реализуется посредством IsbnGenerator и IssnGenerator. Bookservice зависит от интерфейса при генерации номера книги.