Ваши коллеги, возможно, видели только EJB2 и более ранние версии, которые действительно были нечестивыми зверями, которыми очень мало людей пользовались.
В EJB2, для самых простых вещей, нужно было реализовать очень инвазивные фреймворки сбезумные методы жизненного цикла, для которых разработчик должен был предоставить реализацию, но которые не имели ничего общего с (бизнес) целями разработчика.Необходимо было предоставить несколько таких артефактов.
Кроме того, каждый бин должен был синхронизироваться с записями в очень подробном и трудно читаемом дескрипторе развертывания (XML-файл).Как будто это не было достаточно оскорбительно для разработчика, нужно было использовать специальные инструменты для «улучшения» компонента и создания прокси-классов, скелетов и заглушек.Общие ОО вещи, такие как наследование, не поддерживаются.Существовал своего рода инъекция, но странная, которая заключалась в размещении вещей в виде карты (фактически, каталога), связанной с каждым компонентом.
Исходная модель EJB 1 вынуждала все коммуникации быть удаленными и все объектыдля распространения (EJB изначально рассматривались только как технология удаленного взаимодействия).Таким образом, чтобы получить преимущества EJB, вы также были вынуждены распространять свою архитектуру, даже если это было совершенно ненужно.
Возможно, самым большим оскорблением для всех была концепция Entity Bean (не путать с JPAлица).Ошибки с этим типом bean-компонента были настолько велики, что даже самые крупные сторонники EJB в то время едва могли рекомендовать его кому-либо.
Тогда как очень практическая проблема, не очень хорошая совместимость между реализациями EJBв мере.В особенности Entity Beans требовалось огромное количество конфигурации, специфичной для конкретного поставщика.
В довершение всего, для реализации EJB требовались тяжелые (с точки зрения установленного размера и требуемой памяти) серверы приложений, которые были с закрытым исходным кодом и довольно дорогими (что мешалокомпании от модернизации или перехода, потому что инвестиции должны были быть сначала окуплены).Я не могу вспомнить, чтобы многие люди в то время писали о технологии в блогах, и, насколько я помню, отделы продаж в основном передавали технологии менеджерам крупных корпораций.
Неудивительно, что технология не быладействительно любимый средним разработчиком.
Sun как раз вовремя осознала, что технология движется в совершенно неверном направлении, развернулась на 180 ° и начала масштабную работу по реинжинирингу.
В результате EJB 3 (2006) является очень разумным и легковесным подходом.Для реализации не требуется никаких обязательных интерфейсов платформы, не требуется XML, требуется кодировать только один компонент (просто простой POJO), везде есть разумные значения по умолчанию (соглашение по конфигурации), никаких специальных инструментов не требуется (обычный javac будетdo), и использование простых bean-компонентов локально на самом деле является обычным делом в настоящее время.
Bean-объекты Entity были настолько испорчены, что были полностью отброшены и заменены более разумным подходом, поддерживаемым TopLink и Hibernate среди других.
Объедините это с широкой доступностью бесплатных, легких и открытых реализаций в сочетании со многими известными блоггерами, защищающими эту технологию (например, Адам Бьен, Режа Рахман, Гэвин Кинг), и возвращение к популярности легко объяснить.
Недавно было опубликовано несколько руководств по переходу с Spring на Java EE, и они получили очень благоприятное количество голосов на различных новостных сайтах, и многие люди выразили свою поддержку EJB как очень дурацкого человека.г технологии сейчас.Это было бы немыслимо полдесятилетия назад (когда EJB 3 только что был выпущен и еще не очень известен).
Наиболее распространенной альтернативой EJB является Spring Core (Spring Beans).На данный момент я думаю, что у Spring нет явных преимуществ перед EJB и наоборот.Две технологии очень похожи.Spring предлагает еще несколько удобных утилит, в то время как EJB концептуально более легкий (без XML).Оба преимущества несколько субъективны.Как правило, они вдохновлены функциональностью друг друга, и то, кто немного впереди, часто зависит от того, какая технология в последний раз выпустила новую версию.