DI / CDI — Основы

Введение (основы DI / CDI)

Прежде всего, я бы предположил, что в этом есть некоторая путаница, но правда в том, что они одинаковы — разница в том, что использование и его цель.

DI (Dependency Injection) — это общий термин — в основном это функция, которая выполняет процесс обнаружения и подключения компонентов в любом приложении. Это не только вы используете его в своем приложении, вы также можете использовать его в своих модульных тестах и ​​макетах. Конечно, существует множество платформ DI, у вас есть: Guice, Seam, Spring (Seam и Spring расширили схему DI и создали свою собственную), EJB 3.x и сам CDI.

CDI, с другой стороны, сочетает в себе все эти технологии и обеспечивает жизненный цикл компонентов — это позволило объединить технологии DI, чтобы сделать разработку новых функций простой и в основном выполнимой; Вы можете комбинировать сопоставления жизненного цикла Seams с Spring MVC с JPA в качестве его уровня персистентности — все эти технологии были созданы отдельно, но вместе с CDI, разработчики приложений могут объединять их для создания и разработки приложений JEE.

Мне нужно будет разбить темы, так как я определенно утомил бы всех словами и буквами вот так:

1. Основы DI / CDI
2. Основная инъекция
3. Квалификаторы, Область
4. DI / CDI Advance

Я буду создавать отдельные посты для каждого!

Давайте начнем!

SPI (интерфейс сервисного программирования)

У этого также есть так называемый SPI — очевидно, набор функций наряду с API, но имеет совершенно другое назначение.

• API — это описание классов / интерфейсов / методов /…, которые вы вызываете и используете для достижения цели.
• SPI — это описание классов / интерфейсов / методов /…, которые вы расширяете и внедряете для достижения цели.

С SPI вы можете расширить JEE6, создав собственную платформу, демонстрирующую переносимость и расширяемость. ( Но я углублюсь в это позже ).

Почему CDI для JEE6?

CDI был в JEE5 (J2EE) и имел большой успех. Многие новые разработки выигрывают от его подхода, который в конечном итоге упрощает общий процесс разработки. Несколько причин, почему CDI был улучшен в JEE6.

• JEE5 поддерживает внедрение ресурсов, но в нем все еще отсутствует зависимость общего назначения — он поддерживает только @EJB, @PersistenceContext, @PersistenceUnit, @Resources) — конечно, за исключением Spring, в котором представлены разные аннотации для управления жизненным циклом бина
• Внедрение не по типу (и слабое) — имя строки и XML-инъекция действительно хрупки. Улучшение основанного на типах инъекций позволяет улучшить инструменты в целом.

терминология

CDI — внедрение контекста и зависимостей

сваривать

• Эталонная реализация JSR 299 — эталонная реализация — это SPI, используемый для добавления конкретной реализации JSR.
• Обеспечивает расширенную поддержку CDI для контейнера сервлетов.
• Улучшения CDI для авторов расширений.
• Архетипы Maven для CDI и Java EE (я люблю maven!).

Тема CDI: слабая связь и сильный тип

Слабая связь просто означает, что объекты слабо независимы от объектов, которые их используют или используют в настоящее время. CDI представляет новые функции для развязки, такие как классификаторы , улучшает перехватчики , декораторы , производителя сообщений, потребителя и механизмы, лежащие в его основе. Далее мы углубимся в каждый пример, посвященный теме CDI.

Строгая типизация — просто означает строгое объявление bean-компонентов, позволяя контейнеру создавать и отображать конкретные имена для объектов. Это избавляет от необходимости делать именование бинов на основе строк, приведение почти не требуется, так как приведение выполняется контейнером (используя преимущества квалификаторов).

Боб (Что это?)

Технически существует много форм bean-компонентов: у вас есть JSF Bean, EJB Bean, Spring, Seam, Guice CDI, Entity Beans и т. Д., Но, в конечном счете, это просто POJO, которые имеют специальное определение — определение, которое было определено в Managed Bean 1.0 — спецификация сделана в Java EE6. Это означает, что любые POJO могут быть компонентами любого типа, при условии, что они соответствуют стандартам спецификации, что еще больше упрощает процесс объявления и разработки. Контейнер выполняет работу по управлению POJO и добавит поддержку для него, предоставляя / представляя общие базовые сервисы, такие как:

• Управление жизненным циклом (@PostConstruct, @PreDestory)
• Инъекция ресурса (@Resource)
• Перехватчик (@Interceptors, @ArounInvoke)

Имея это в виду, как насчет EJB , REST и компонентов CDI ?

• EJB bean-компонент, управляемый службой, с общими службами (см. Выше) и поддержкой транзакций, безопасности, безопасности потоков и постоянства.
• Служба bean-компонента REST — управляемый компонент с поддержкой HTTP
• Компонент CDI — управляемый компонент с поддержкой жизненного цикла:
  • Авто открытие
  • Отборочные
  • Сфера
  • EL
  • Перехватчики и декораторы
  • Альтернативный компонент (от спецификатора во время выполнения)

В перспективе Manage Bean — это SPI, расширенный для конкретного использования. EJB, Rest, Entity Bean — это управляемые EJB-компоненты, но с дополнительными сервисами из контейнера. Таким образом, если вы определяете POJO с помощью аннотации @Stateless или @Stateful, контейнер автоматически обнаруживает, что это EJB-компонент, и ему требуется специфическая поддержка контейнера, такая как транзакции, безопасность, безопасность потоков, расширения и т. Д.

Простой класс POJO превратился в bean-компонент без сохранения состояния с легким движением пальца (фактически введенного), что привело к тому, что один вкладыш @Stateless code. В отличие от того, как EJB был определен на априорных 3.x (такая боль).

Загрузите образец (выше) отсюда: нажмите меня

Автоматическое обнаружение бобов

Контейнер CDI является тем, кто отвечает за то, как бины обнаруживаются, но как он это делает?

1. Сначала выполняется сканирование пути к классам, который содержит архивы приложений и контейнеров.
   1. Он пытается просканировать путь к классам и посмотреть, какие POJO являются тегами для обнаружения, то есть Managed Bean. Вы можете думать об этом, что он помещает в пул и может быть легко доступен, когда другой управляемый компонент вызывает его через инъекцию (подробнее об этом в следующей теме блога)
2. Затем он обнаруживает присутствие beans.xml (или любое определение XML-файла контекста).
   1. Для поклонников Spring это очень похоже на applicationContext.xml (по крайней мере, это соглашение, но не очень) — вы передаете этот xml в слушатель contextConfiguration (параметр через) и Spring CDI Container автоматически помечает объекты (бины) в нем для обнаружения. — конечно, вам нужно определить механизмы сканирования (компонент-сканирование).

В конечном счете, DI / CDI был введен для упрощения процесса разработки, унификации технологий и в целом для создания более надежного, расширяемого приложения. Разрешение всему контейнеру выполнять работу с помощью тегирования общих служб bean-компонента облегчает задачу разработчика и позволяет избежать ошибок, возникающих в результате предыдущих платформ. SPI — это действительно определение улучшения, позволяющее расширять структуру JEE6, что создает более динамичный характер — теперь архитекторы бизнес-приложений могут разрабатывать свои собственные рамки и соглашения. Добавьте больше специфичных для бизнеса проектов или аннотаций для своих собственных правил и предоставьте надежность и гибкость, которые всегда требуются для корпоративных приложений.

Следующая тема: Basic Injection — я не хочу помещать все в один пост, поэтому я оставлю это на ваше усмотрение, чтобы сначала изучить и проверить созданный мной образец. С этого момента я расскажу подробнее о примерах DI и CDI.