Як порівняти CDI та EJB? взаємодіяти?

Мені важко зрозуміти, як вони взаємодіють і де лежить межа між ними. Вони перетинаються? Чи є надмірності між ними?

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

Дійсно просто заплутався. Я (думаю, що я) розумію EJB досить добре, я думаю, що мені важко зрозуміти, що саме CDI подає до столу, і як він витісняє або покращує те, що EJB вже пропонує.

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. оновлене посилання на приклад

Наразі це справді трохи заплутано, оскільки зараз у Java EE є багатокомпонентні моделі. Це CDI , EJB3 та JSF Managed Beans .

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

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

Ін'єкційна залежність в зернах EJB3 не така гнучка, як у квасолі CDI, а EJB3 в бобах не має поняття визначення обсягу. Однак боби EJB3 є транзакційними та об'єднаними за замовчуванням ^** , дві дуже корисні речі, які CDI вирішив залишити у домені EJB3. Інші згадані елементи також відсутні в CDI. EJB3 не має власної шини подій, але він має особливий тип боб для прослуховування повідомлень; повідомлення, кероване бобом. Це можна використовувати для отримання повідомлень із системи обміну повідомленнями Java або з будь-якої іншої системи, яка має адаптер ресурсів JCA. Використання повнофункціональних повідомлень для простих подій набагато важче, ніж шина подій CDI, і EJB3 визначає лише слухача, а не API виробника.

Бобові керовані JSF існували в Java EE з моменту включення JSF. Вони занадто характерні dependency injectionі scoping. JSF Managed Beans представив концепцію декларативної оцінки. Спочатку сфери застосування були досить обмеженими, і в тій же версії Java EE, де боби EJB3 вже можна було оголосити за допомогою анотацій, керовані боби JSF все ще повинні були бути оголошені в XML. Поточна версія керованих бобів JSF також остаточно декларується за допомогою анотації, а сфери розширення розширюються з огляду області та можливості створення спеціальних областей. Область перегляду, яка запам'ятовує дані між запитами на одну і ту ж сторінку, є унікальною особливістю керованих бобів JSF.

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

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

Реза Рахман, член експертної групи та реалізатор впровадження CDI під назвою CanDI, часто натякає, що послуги, пов'язані з компонентною моделлю EJB3, можуть бути оновлені як набір анотацій CDI. Якби це сталося, усі керовані боби в Java EE можуть стати CDI-бобами. Це не означає, що EJB3 зникає або застаріває, але просто те, що його функціональність буде відкрита через CDI замість власних приміток EJB, таких як @Stateless та @EJB.

Оновлення

Девід Блевінс із слави TomEE та OpenEJB дуже добре пояснює відмінності та схожість між CDI та EJB у своєму блозі: CDI, коли потрібно вибувати з EJB

_{* Хоча це лише приріст кількості версії, боби EJB3 здебільшого були абсолютно іншим видом бобів: простий пуджо, який стає "керованим бобом", застосовуючи просту одиночну анотацію, порівняно з моделлю в EJB2, де важковаговик і дескриптор розгортання XML був потрібний для кожного компонента, на додаток до бону, необхідного для впровадження різних надзвичайно важких і здебільшого безглуздих компонентних інтерфейсів.}

_{** Бобові сеанси без громадянства, як правило, об'єднані, боби, що належать до сеансів, зазвичай не є (але вони можуть бути) Таким чином, об'єднання обох типів є необов'язковим, і специфікація EJB не вимагає цього.}

Альберт Ейнштейн: 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 і об'єднуються. Обов'язком системи ЕЕ є надання споживачам примірників.

@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. Тут слід зазначити, що оскільки ми не анотували Specificationклас, він за замовчуванням Анотований @Dependentанотацією.

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

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