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

Внедрение зависимостей (DI) — это шаблон разработки, в котором разделяются зависимые компоненты. Здесь мы имеем дело с инверсией управления, причем инверсии подвергается процесс получения необходимой зависимости. Этот термин был введен Мартином Фаулером. Внедрение зависимостей в такой управляемой среде, как Java EE, можно охарактеризовать как полную противоположность применения интерфейса JNDI. Объекту не приходится искать другие объекты, так как контейнер внедряет эти зависимые сущности без вашего участия. В этом состоит так называемый принцип Голливуда: «Не звоните нам (не ищите объекты), мы сами вам позвоним (внедрим объекты)».

Java EE была создана в конце 1990-х годов, и в самой первой версии уже присутствовали компоненты EJB, сервлеты и служба JMS. Эти компоненты могли использовать JNDI для поиска ресурсов, управляемых контейнером, таких как интерфейс JDBC DataSource, JMS-фабрики либо адреса назначения. Это сделало возможной зависимость компонентов и позволило EJB-контейнеру взять на себя сложности управления жизненным циклом ресурса (инстанцирование, инициализацию, упорядочение и предоставление клиентам ссылок на ресурсы по мере необходимости). Однако вернемся к теме внедрения ресурса, выполняемого контейнером.

В платформе Java EE 5 появилось внедрение ресурсов для разработчиков. Это позволило им внедрять такие ресурсы контейнера, как компоненты EJB, менеджер сущностей, источники данных, фабрики JMS и адреса назначения, в набор определенных компонентов (сервлетов, связующих компонентов JSF и EJB). С этой целью Java EE 5 предоставила новый набор аннотаций (@Resource, @PersistenceContext, @PersistenceUnit, @EJB и @WebServiceRef).

Новшеств Java EE 5 оказалось недостаточно, и тогда Java EE 6 создала еще две спецификации для добавления в платформу настоящего внедрения зависимостей (DI): Dependency Injection (запрос JSR 330) и Contexts and Dependency Injection (запрос JSR 299). На сегодняшний день в Java EE 7 внедрение зависимостей используется еще шире: для связи спецификаций.

Жизненный цикл POJO достаточно прост: вы, Java-разработчик, создаете экземпляр класса, используя ключевое слово new, и ждете, пока сборщик мусора (Garbage Collector) избавится от него и освободит некоторое количество памяти. Но если вы хотите запустить компонент CDI внутри контейнера, вам нельзя указывать ключевое слово new. Вместо этого вам необходимо внедрить компонент, а все остальное сделает контейнер. Тут подразумевается, что только контейнер отвечает за управление жизненным циклом компонента: сначала он создает экземпляр, затем избавляется от него. Итак, как же вам инициализировать компонент, если вы не можете вызвать конструктор? В этом случае контейнер дает вам указатель после конструкции экземпляра и перед его уничтожением.

Рисунок 2.1 показывает жизненный цикл управляемого компонента (следовательно, и компонента CDI). Когда вы внедряете компонент, только контейнер (EJB, CDI или веб-контейнер) отвечает за создание экземпляра (с использованием кодового слова new). Затем он разрешает зависимости и вызывает любой метод с аннотацией @PostConstruct до первого вызова бизнес-метода на компоненте. После этого оповещение с помощью обратного вызова @PreDestroy сигнализирует о том, что экземпляр удаляется контейнером.

Рис. 2.1. Жизненный цикл управляемого компонента

В следующих главах вы увидите, что большинство компонентов Java EE следуют жизненному циклу, описанному на рис. 2.1.

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

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

Методы-перехватчики используются для вставки между вызовами бизнес-методов. Это похоже на аспектно-ориентированное программирование (АОП). АОП — это парадигма программирования, отделяющая задачи сквозной функциональности (влияющие на приложение) от вашего бизнес-кода. Большинство приложений имеют общий код, который повторяется среди компонентов. Это могут быть технические задачи (сделать запись в журнале и выйти из любого метода, сделать запись в журнале о длительности вызова метода, сохранить статистику использования метода и т. д.) или бизнес-логика. К последней относятся: выполнение дополнительных проверок, если покупатель приобретает товар более чем на $10 000, отправка запросов о повторном заполнении заказа, если товара недостаточно в наличии, и т. д. Эти задачи могут применяться автоматически посредством AOP ко всему вашему приложению либо к его подсистеме.

Управляемые компоненты поддерживают функциональность в стиле AOP, обеспечивая возможность перехвата вызова с помощью методов-перехватчиков. Перехватчики автоматически инициируются контейнером, когда вызывается метод управляемого компонента. Как показано на рис. 2.2, перехватчики можно объединять в цепочки и вызывать до и/или после исполнения метода.

Рис. 2.2. Контейнер, перехватывающий вызов и инициирующий метод-перехватчик

Рисунок 2.2 демонстрирует количество перехватчиков, которые вызываются между клиентом и управляемым компонентом. Вы могли подумать, что EJB-контейнер представляет собой цепочку перехватчиков. Когда вы разрабатываете сеансовый объект, вы просто концентрируетесь на бизнес-коде. Но в то же самое время, когда клиент вызывает метод на вашем компоненте EJB, контейнер перехватывает вызов и применяет различные сервисы (управление жизненным циклом, транзакцию, безопасность и т. д.). Без использования перехватчиков вам приходится добавлять собственные механизмы сквозной функциональности и наиболее логичным образом применять их в вашем бизнес-коде.