Что нельзя сделать без EJB


Если JPA не зависит от EJB и имеет свою спецификацию. Зачем мне нужен объект ? Чего я не могу без EJB ?

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

Почему мы должны использовать EJB?

Https://stackoverflow.com/questions/4464338/why-ejb-is-used-in-enterprise-applications

3 4

3 ответа:

Все вышеприведенные ответы добавляют важную информацию к вопросу, но упускают один критический момент. Главным пунктом продажи архитектуры EJB было распределенный компонент (отдельно от всех другие сервисы,такие как container managed, transactional, secure и т. д.). Идея заключалась в том, чтобы позволить бизнес-логике работать в распределенной среде piggybacking на RMI/IIOP. Хотя с годами этот архитектурный стиль оказался плохим. Для распределенных вычислений их было больше успешная архитектура, основанная на веб-сервисах. Распределенные компоненты, хотя и были упрощены EJB, имели свою долю присущих им сложностей и проблем с производительностью, и впоследствии их по возможности избегали. Старое, но очень интересное чтение по этому вопросу Мартина Фаулера можно прочитать здесь, где он язвительно атакует соблазн распределенной архитектуры, обычно продвигаемый подобными EJB. Более поздние люди, по-видимому, следовали этой мудрости и избегали искушение вскочить на подножку" распределенной архитектуры". В Java landscape это ознаменовалось появлением Spring framework и знаменитой книги рода Джонсона "Expert One-on-One J2EE Development without EJB". Люди и подобные мне никогда не пропускали EJB с тех пор: -)

P.S. чтобы быть справедливым к спецификациям EJB и ребятам, упорно работающим над его улучшением, они, безусловно, добились значительного прогресса в последнее десятилетие, и они очень современны и дружелюбны к разработчикам. Однако их "распределенная" природа навсегда отошла на задний план

EJB - это просто серверный компонент, который обслуживает запрос пользователя. Каждый корпоративный Боб работает в контейнере, который выполняет некоторое обслуживание (управление транзакциями, управление безопасностью, жизненный цикл Боба и т. д.,) от имени пользователя / программиста. Таким образом, это заставляет разработчика сосредоточиться на основной работе, а не изобретать все в одиночку.

Таким образом, мы можем заключить, что EJB просто уменьшает объем кодирования, выполняемого программистом, и позволяет программисту сосредоточиться на основной бизнес-логике.

Мы можем сделать то же самое без EJBs с некоторым хорошим количеством кодирования.

Спасибо, JK

EJBs, или enterprise java beans-это классы java, которые могут управляться контейнером Java EE, гарантирующим такие службы, как

  • жизненный цикл бобов
  • управление потоками
  • управление транзакциями и т. д.

Да, JPA теперь не является частью спецификации Java EE. Он перешел на JSE. Однако в прошлом, когда Entity Beans обеспечивали "стандартный" мост между java и миром реляционных баз данных.

Что вы не можете сделать без EJB? Я бы ничего не сказал. Я имею в виду, что вы можете сделать все без Эйба. И причина в том, что существуют альтернативные решения, такие как Spring или Guice.

И, как всегда, вы можете писать код более низкого уровня без каких-либо рамок.