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

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

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

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

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

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

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

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

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

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