Читаем Изучаем Java EE 7 полностью

Как видите, все области видимости имеют аннотацию, которую вы можете использовать с вашими компонентами 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 показывает компонент в пределах диалога, реализующий мастер для создания нового пользователя.


Листинг 2.21. Мастер для создания учетной записи пользователя с применением диалога

@ConversationScoped

public class CustomerCreatorWizard implements Serializable {

··private Login login;

··private Account account;

··@Inject

··private CustomerService customerService;

··@Inject

··private Conversation conversation;

··public void saveLogin() {

····conversation.begin();

····login = newLogin();

····// Задает свойства учетных данных

··}

Перейти на страницу:

Похожие книги

C# 4.0: полное руководство
C# 4.0: полное руководство

В этом полном руководстве по C# 4.0 - языку программирования, разработанному специально для среды .NET, - детально рассмотрены все основные средства языка: типы данных, операторы, управляющие операторы, классы, интерфейсы, методы, делегаты, индексаторы, события, указатели, обобщения, коллекции, основные библиотеки классов, средства многопоточного программирования и директивы препроцессора. Подробно описаны новые возможности C#, в том числе PLINQ, библиотека TPL, динамический тип данных, а также именованные и необязательные аргументы. Это справочное пособие снабжено массой полезных советов авторитетного автора и сотнями примеров программ с комментариями, благодаря которым они становятся понятными любому читателю независимо от уровня его подготовки. Книга рассчитана на широкий круг читателей, интересующихся программированием на C#.Введите сюда краткую аннотацию

Герберт Шилдт

Программирование, программы, базы данных
97 этюдов для архитекторов программных систем
97 этюдов для архитекторов программных систем

Успешная карьера архитектора программного обеспечения требует хорошего владения как технической, так и деловой сторонами вопросов, связанных с проектированием архитектуры. В этой необычной книге ведущие архитекторы ПО со всего света обсуждают важные принципы разработки, выходящие далеко за пределы чисто технических вопросов.?Архитектор ПО выполняет роль посредника между командой разработчиков и бизнес-руководством компании, поэтому чтобы добиться успеха в этой профессии, необходимо не только овладеть различными технологиями, но и обеспечить работу над проектом в соответствии с бизнес-целями. В книге более 50 архитекторов рассказывают о том, что считают самым важным в своей работе, дают советы, как организовать общение с другими участниками проекта, как снизить сложность архитектуры, как оказывать поддержку разработчикам. Они щедро делятся множеством полезных идей и приемов, которые вынесли из своего многолетнего опыта. Авторы надеются, что книга станет источником вдохновения и руководством к действию для многих профессиональных программистов.

Билл де Ора , Майкл Хайгард , Нил Форд

Программирование, программы, базы данных / Базы данных / Программирование / Книги по IT