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

В самой первой версии Java EE (в то время именуемой J2EE) была представлена концепция инверсии управления (IoC), в рамках которой контейнер обеспечивал управление вашим бизнес-кодом и предоставлял технические сервисы (такие как управление транзакциями или безопасностью). Это подразумевало управление жизненным циклом компонентов, а также предоставление компонентам внедрения зависимостей и конфигурации. Данные сервисы были встроены в контейнер, и программистам пришлось дожидаться более поздних версий Java EE, чтобы получить к ним доступ. Конфигурация компонентов в ранних версиях стала возможной благодаря дескрипторам развертывания XML, однако простой и надежный API для управления жизненным циклом и внедрения зависимостей появился только в Java EE 5 и Java EE 6.

Версия Java EE 6 предоставила контекст и внедрение зависимостей (Context and Dependency Injection — CDI) для упрощения некоторых задач, фактически став центральной спецификацией, объединившей все эти концепции. Сегодня CDI дает управляемым объектам EJB одну из наиболее приоритетных моделей программирования. Она преобразует практически все сущности Java EE в управляемые компоненты, которые можно внедрять и перехватывать. Концепция CDI основана на принципе «слабой связанности и строгой типизации». Это означает, что компоненты связаны слабо, но при этом строго типизированы. Добавление в платформу перехватчиков, декораторов и событий придает ей дополнительную гибкость. И в то же время CDI соединяет веб-уровень и серверную часть путем гомогенизации областей видимости.

В этой главе рассказывается о внедрении зависимостей, ограничении и слабой связанности, то есть здесь охватывается большинство концепций, лежащих в основе CDI.

Понятие компонентов

В Java SE имеются компоненты JavaBeans, а в Java EE — Enterprise JavaBeans. Но Java EE также использует другие типы компонентов: сервлеты, веб-службы SOAP и RESTful, сущности и, конечно, управляемые компоненты. Не стоит забывать и об объектах POJO. POJO — это просто Java-классы, запускаемые в пределах виртуальной машины Java (JVM). JavaBeans — это те же объекты POJO, которые следуют определенным шаблонам (например, правилам именования для процессов доступа и модифицирующих методов (геттеров/сеттеров) для свойства, конструктора по умолчанию) и исполняются в пределах JVM. Все остальные компоненты Java EE также следуют определенным шаблонам: например, компонент Enterprise JavaBean должен иметь метаданные, конструктор по умолчанию не может быть конечным, и т. д. Они также выполняются внутри контейнера (например, контейнера EJB), который предоставляет определенные сервисы: например, транзакции, организацию пула, безопасность и т. д. Теперь поговорим о простых и управляемых компонентах.

Управляемые компоненты — это объекты, которые управляются контейнером и поддерживают только небольшой набор базовых сервисов: внедрение ресурса, управление жизненным циклом и перехват. Они появились в Java EE 6, обеспечив более легковесную компонентную модель, приведенную в соответствие с остальной частью платформы Java EE. Они дают общее основание различным типам компонентов, существующих в платформе Java EE. Например, Enterprise JavaBean может рассматриваться как управляемый компонент с дополнительными сервисами. Сервлет также может считаться управляемым компонентом с дополнительными сервисами (отличным от EJB) и т. д.

Компоненты — это объекты CDI, основанные на базовой модели управляемых компонентов. Они имеют улучшенный жизненный цикл для объектов с сохранением состояния; привязаны к четко определенным контекстам; обеспечивают сохранение безопасности типов при внедрении зависимостей, перехвате и декорации; специализируются с помощью аннотаций квалификатора; могут использоваться в языке выражений (EL). По сути, с очень малым количеством исключений потенциально каждый класс Java, имеющий конструктор по умолчанию и исполняемый внутри контейнера, является компонентом. Поэтому компоненты JavaBeans и Enterprise JavaBeans также могут воспользоваться преимуществами этих сервисов CDI.

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

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

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

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

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

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

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

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

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

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

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