Как CDI и EJB сравниваются? взаимодействовать? - PullRequest
Новая
       46

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

103 голосов
/ 13 января 2011

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

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

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

Ответы [ 3 ]

186 голосов
/ 16 января 2011

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

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

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

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

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

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

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

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

Update

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

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

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

47 голосов
/ 13 января 2011

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. обновлена ​​ссылка на пример

0 голосов
/ 09 августа 2018

Альберт Эйнштейн: If you can't explain it simply, you don't understand it well enough

Ejbs и CDI довольно просты для понимания.

Ejbs:

  1. Всегда будет комментироваться квалификаторами области, например, @Stateless, @Stateful, @Request и т. Д.
  2. Экземпляры Ejbs контролируются инфраструктурой Java EE и объединяются. Обязанность EE Framework - предоставлять экземпляры для потребителя.

@Stateless

 public class CarMaker(){
    public void createCar(Specification specs){
        Car car = new Car(specs);
    }
}

CarMaker аннотируется с определенной областью Ejbs, поэтому это Ejb

CDI:

  1. Не управляется полностью EE-фреймворком, экземпляры должны создаваться самим.

  2. Это всегда зависит. позвольте мне объяснить «Зависимый» с примером:

    class Specification { private String color; private String model; //- Getter and Setter }

Класс Specification является CDI, поскольку он не аннотирован областями Ejb, а также должен инициализироваться вашим кодом, а не EE framework. Здесь следует отметить, что, поскольку мы не аннотировали класс Specification, он по умолчанию аннотируется аннотацией @Dependent. 

@Dependent  <- By default added 
class Specification { ... }

Further reading: Вам нужно больше изучить между аннотацией области Ejbs и аннотацией области CDI, что еще больше прояснит концепцию

...