Spring + Hibernate предпочтительнее, чем EJB 3?

Я считаю, что всякий раз, когда начинаются новые проекты JEE (где эти технологии будут применимы), люди предпочитают использовать комбинацию Spring + Hibernate вместо EJB 3.

Кажется, что младшим программистам даже советуют пойти на это вместо EJB.

Это личное предпочтение или есть соответствующие причины? (например, личные шрамы, созданные более ранними версиями EJB, которые вызывали недоверие к EJB или вздутие технологий по сравнению с причинами производительности или кривой обучения)?

Фреймворки EJB 3+ на самом деле довольно хороши, поскольку они пришли вместе с JPA в качестве ответа для фреймворков, настроенных для аннотаций, а также для CDI, который позволяет внедрять зависимости, настроенные для аннотаций. Вы также добавляете поверх этого Weld. Spring, с другой стороны, только сейчас догоняет игру с настройкой через аннотации.

При этом историческое отставание от EJB1 и 2 не следует сбрасывать со счетов. Они не просто не смогли решить проблемы с написанием корпоративных приложений, они эффектно провалились. Это была полная неспособность дизайнеров получить представление об истинных проблемах, с которыми сталкиваются разработчики корпоративных приложений и веб-приложений, и, в свою очередь, предложить решения, которые им действительно необходимы.

Добавьте к этому недоверие к существующим в настоящее время серьезным потрясениям и нестабильности в текущем направлении Java, а также недоверие к нынешним управляющим и владельцам старой Sun JVM в Oracle. Многие люди не верят в то, что Oracle улучшит Java и возглавит руководство, и есть также опасение, что Apache Software Foundation может просто бросить полотенце. Все больше и больше людей обращаются к OpenJDK за будущим Java, но это не то, что нужно для принятия Enterprise.

Некоторые считают все это запахом смерти, поскольку корпоративные приложения являются основными причинами того, что Java исторически является языком программирования № 1 в мире на протяжении столь длительного времени. Вот почему Microsoft так много делает против Java с технологиями .NET.

Разработчики Java-приложений не на корпоративном уровне все больше обращаются к OpenJDK и другим средам с открытым исходным кодом, чтобы помочь в создании своих решений, а некоторые никогда не оглядываются назад. Можно сказать, что это слишком поздно, чтобы вернуть JEE на передний план легитимности, хотя технически JEE может и действительно стоит на одном уровне с вашим сопоставимым приложением Spring.

У EJB много багажа. Часть этого багажа происходит из-за того, что он был нацелен не на ту аудиторию. Другая часть состояла в том, что первые две версии были полным дерьмом.

Если вы посмотрите на оригинальные версии EJB, то разработчик EJB мог создать пакетное решение, которое можно было бы использовать в любом EJB-совместимом контейнере. Для внутреннего магазина этот уровень абстракции был ненужным. Это было идеальное решение для создания процветающего рынка для сторонних поставщиков компонентов EJB. Тем не менее, поставщики контейнеров были слишком усердны в своем маркетинге и делали тонны, продавая свой продукт как жизнеспособное решение для повседневной разработки. Это было бы эквивалентно созданию всего кода вашего приложения в качестве компонентов COM +.

Для получения дополнительной информации о первоначальной спецификации J2EE большинство вовлеченных поставщиков имели серверы CORBA и хотели использовать эти продукты в будущем. Спецификация EJB была построена на протоколе IIOP (на самом деле Java RMI, который был тонким слоем над IIOP). CORBA уже была отклонена из-за ее сложности, и EJB был просто замаскированным CORBA, поэтому он принес с собой многие из проблем, которые были у CORBA. На самом деле, абстракции EJB усложняли работу с ними, чем была бы чистая реализация CORBA.

Как только резина ударила об асфальт, люди поняли, что выступление с EJB было ужасным. С каждым вызовом, являющимся удаленным вызовом, и трудностью даже с самого начала правильно запустить и запустить приложение, люди быстро искали альтернативы. Решением стали Hibernate и Spring, работающие в контейнере JSP.

EJB 3 «принял» этот подход. Но это все еще общий компромисс, который не дает большой выгоды. Стороннего рынка EJB-компонентов по-прежнему не существует, поэтому на самом деле нет смысла использовать EJB-контейнер для построения вашего решения.

Короче. Хотя EJB 3 является значительным улучшением по сравнению с первыми двумя итерациями, он все еще не дает достаточных преимуществ, чтобы перевесить затраты.