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

• Область видимости диалога (@ConverationScoped) — действительна между множественными вызовами в рамках одной сессии, ее начальная и конечная точка определяются приложением. Диалоги используются среди множественных страниц как часть многоступенчатого рабочего потока.

• Зависимая псевдообласть видимости (@Dependent) — ее жизненный цикл совпадает с жизненным циклом клиента. Зависимый компонент создается каждый раз при внедрении, а ссылка удаляется одновременно с удалением целевой точки внедрения. Эта область видимости по умолчанию предназначена для CDI.

Как видите, все области видимости имеют аннотацию, которую вы можете использовать с вашими компонентами CDI (все эти аннотации содержатся в пакете javax.enterprise.context). Первые три области видимости хорошо известны. Например, если у вас есть компонент «Корзина», чья область видимости ограничена одним сеансом, компонент будет создан автоматически, когда начнется сессия (например, во время первой регистрации пользователя в системе), и автоматически будет разрушен по окончании сессии.

@SessionScoped

public class ShoppingCart implements Serializable {…}

Экземпляр компонента ShoppingCart связан с сеансом пользователя и используется совместно всеми запросами, выполняемыми в контексте этой сессии. Если вы не хотите, чтобы компонент находился в сеансе неопределенно долго, подумайте о том, чтобы задействовать другую область видимости с более коротким временем жизни, например область видимости запроса или диалога. Обратите внимание, что компоненты с областью видимости @SessionScoped или @ConversationScoped должны быть сериализуемыми, так как контейнер периодически пассивизирует их.

Если область видимости явно не обозначена, то компонент принадлежит зависимой псевдообласти видимости (@Dependent). Компоненты с такой областью видимости не могут совместно использоваться несколькими клиентами или через несколько точек внедрения. Их жизненный цикл связан с жизненным циклом компонента, от которого они зависят. Зависимый компонент инстанцируется, когда создается объект, к которому он относится, и разрушается, когда такой объект уничтожается. Следующий отрывок кода показывает зависимый ограниченный ISBN-генератор с квалификатором:

@Dependent @ThirteenDigits

public class IsbnGenerator implements NumberGenerator {…}

Поскольку это область видимости по умолчанию, вы можете опустить аннотацию @Dependent и написать следующее:

@ThirteenDigits

public class IsbnGenerator implements NumberGenerator {…}

Области видимости могут быть смешанными. Компонент с аннотацией @SessionScoped можно внедрить в @RequestScoped или @ApplicationScoped и наоборот.

Диалог.Область видимости диалога несколько отличается от областей видимости приложения, сеанса или запроса. Она хранит состояние, ассоциированное с пользователем, распространяется сразу на много запросов и программно отграничивается от остального кода на уровне приложения. Компонент с аннотацией @ConversationScoped может использоваться для длительных процессов, имеющих начало и конец, таких как навигация по мастеру или покупка товаров и подтверждение и оплата заказа.

Объекты, область видимости которых ограничена одним запросом (HTTP-запросом или вызовом метода), обычно существуют очень недолго, тогда как объекты с областью видимости в пределах сеанса существуют на протяжении всего пользовательского сеанса. Однако есть много случаев, которые не относятся к этим двум крайностям. Отдельные объекты уровня представлений могут использоваться более чем на одной странице, но не на протяжении целой сессии. Для этого в CDI есть специальная область видимости диалога (@ConversationScoped). В отличие от объектов в пределах сеанса, которые автоматически отключаются контейнером по истечении заданной задержки, объекты в пределах диалога имеют четко определенный жизненный цикл, который явно начинается и явно заканчивается, причем начало и окончание задаются программно с помощью API javax.enterprise.context.Conversation.

В качестве примера рассмотрим следующее веб-приложение: мастер для создания новой учетной записи клиента. Мастер состоит из трех шагов. В первом шаге клиент вводит данные для входа в систему, например имя пользователя и пароль. Во втором шаге пользователь вводит данные учетной записи, например имя, фамилию, почтовый адрес и адрес электронной почты. Во время последнего шага мастер подтверждает всю собранную информацию и создает учетную запись. Листинг 2.21 показывает компонент в пределах диалога, реализующий мастер для создания нового пользователя.