Как сравнивать CDI и EJB? взаимодействовать?

Мне сложно понять, как они взаимодействуют и где находится граница между ними. Они перекрываются? Есть ли у них избыточность?

Я знаю, что есть аннотации, связанные с обоими, но я не смог найти полный список для обоих с краткими описаниями. Не уверен, что это поможет понять, как они отличаются или где они перекрываются.

На самом деле просто путают. Я (думаю, я) понимаю EJB достаточно хорошо, я думаю, мне трудно понять, что именно CDI приносит к столу и как он вытесняет или улучшает то, что уже предлагает EJB.

ОТВЕТЫ

Ответ 1

CDI - речь идет об инъекции зависимостей. Это означает, что вы можете внедрять реализацию интерфейса в любом месте. Этот объект может быть любым, он не может быть связан с EJB. Здесь приведен пример того, как вводить случайный генератор с использованием CDI. В EJB ничего нет. Вы собираетесь использовать CDI, если хотите внедрить службы, отличные от EJB, различные реализации или алгоритмы (так что вам вообще не нужен EJB).
EJB, который вы понимаете, и, вероятно, вас смущает аннотация @EJB - это позволяет вам внедрить внедрение в вашу службу или что-то еще. Основная идея заключается в том, что класс, в который вы вводите, должен управляться контейнером EJB. Кажется, что CDI действительно понимает, что такое EJB, поэтому на сервере, совместимом с Java EE 6, в вашем сервлете вы можете написать как

@EJB EJBService ejbService;

и

@Inject EJBService ejbService;

что может заставить вас запутать, но это, вероятно, единственное, что является мостом между EJB и CDI.

Когда мы говорим о CDI, вы можете вводить другие объекты в управляемые классы CDI (они должны быть созданы только с помощью CDI-совместимых фреймворков).

Что еще CDI предлагает... Например, вы используете Struts 2 как среду MVC (просто пример), и вы ограничены здесь, даже используя EJB 3.1 - вы не можете использовать аннотацию @EJB в действии Struts, это не управляемый контейнером. Но когда вы добавляете плагин Struts2-CDI, вы можете написать там аннотацию @Inject для одной и той же вещи (поэтому больше не нужно искать JNDI). Таким образом, он усиливает мощность EJB. Но, как я уже упоминал ранее, что вы вводите с CDI - не имеет значения, связано ли это с EJB или нет, и что его мощность

PS. обновленная ссылка на пример

Ответ 2

В настоящее время это действительно немного запутанно, так как в Java EE есть несколько компонентных моделей. Они CDI, EJB3 и JSF Managed Beans.

CDI - новый ребенок на блоке. CDI beans dependency injection, scoping и event bus. CDI beans являются наиболее гибкими по отношению к инъекции и определению диапазона. Шина событий очень легкая и очень хорошо подходит даже для самых простых веб-приложений. В дополнение к этому, CDI также предоставляет очень продвинутую функцию под названием portable extensions, которая является своего рода подключаемым механизмом для поставщиков, обеспечивающим дополнительную функциональность Java EE, которая может быть доступна для всех реализаций (Glassfish, JBoss AS, Websphere, и т.д.).

EJB3 beans были модернизированы из старой модели EJB2 старого класса * и были первыми beans в Java EE, которые будут управляться beans через аннотацию, EJB3 beans имеет функцию dependency injection, declarative transactions, declarative security, pooling, concurrency control, asynchronous execution и remoting.

Включение зависимостей в EJB3 beans не так гибко, как в CDI beans, а EJB3 beans не имеет понятия о масштабах. Однако EJB3 beans являются транзакционными и объединяются по умолчанию ** две очень пригодные для использования вещи, которые CDI выбрал оставить в домене EJB3. Другие упомянутые элементы также недоступны в CDI. EJB3 не имеет собственной шины событий, но имеет специальный тип bean для прослушивания сообщений; сообщение bean. Это можно использовать для приема сообщений из системы обмена сообщениями Java или из любой другой системы с адаптером ресурсов JCA. Использование полномасштабной передачи сообщений для простых событий намного более тяжело, чем шина событий CDI, и EJB3 определяет только слушателя, а не API-производителя.

JSF Managed Beans существовал в Java EE с момента включения JSF. Они также имеют dependency injection и scoping. JSF Managed beans представил концепцию декларативного охвата. Первоначально области были довольно ограниченными и в той же версии Java EE, где EJB3 beans уже можно было объявить через аннотации, JSF Managed beans все еще должен был быть объявлен в XML. Текущая версия JSF Managed beans также окончательно объявляется через аннотацию, а области охвата расширяются с помощью области представления и возможности создавать собственные области. Область просмотра, которая запоминает данные между запросами на странице same, является уникальной функцией JSF Managed Beans.

Помимо области просмотра, в JEF Managed beans в Java EE 6 еще мало что происходит. Недостающая область видимости в CDI несчастлива, поскольку в противном случае CDI был бы идеальным супер-набором того, что управляло JSF beans предложение. Обновление: в Java EE 7/JSF 2.2 добавлен совместимый с CDI @ViewScoped, что делает CDI действительно идеальным задавать.

С EJB3 и CDI ситуация не такая четкая. Модель компонента EJB3 и API предлагают множество услуг, которые CDI не предлагает, поэтому обычно EJB3 не может быть заменен CDI. С другой стороны, CDI может использоваться в комбинации с EJB3 - например, добавление поддержки поддержки EJB.

Реза Рахман, член группы экспертов и разработчик реализации CDI под названием CanDI, часто намекала, что сервисы, связанные с моделью компонентов EJB3, могут быть модифицированы как набор аннотаций CDI. Если это произойдет, все управляемые beans в Java EE могут стать CDI Beans. Это не означает, что EJB3 исчезает или становится устаревшим, но только то, что его функциональность будет отображаться через CDI, а не через собственные аннотации EJB, такие как @Stateless и @EJB.

Обновление

Дэвид Блевинс из славы TomEE и OpenEJB очень хорошо объясняет различия и сходства между CDI и EJB в своем блоге: CDI, когда выходить из EJB

<суб > * Хотя это просто увеличение номера версии, EJB3 beans были по большей части совершенно другим видом bean: простым pojo, которое становится "управляемым bean", применяя простую единую аннотацию, а также модель в EJB2, где для каждого и каждого bean требовался избыточный и чрезмерно подробный дескриптор развертывания XML, в дополнение к bean, требуемому для реализации различных чрезвычайно тяжелых и по большей части бессмысленных интерфейсов компонентов.

** Сеанс без учета состояния beans обычно объединяются, сеанс с состоянием beans обычно не (но они могут быть). Для обоих типов объединение пула, таким образом, является необязательным, и спецификация EJB не предоставляет ему никаких ограничений.