Должен ли я использовать EJB3 или Spring для своего бизнес-уровня?

Question

Моя команда разрабатывает новый сервис-ориентированный продукт с веб-интерфейсом.При обсуждении того, какие технологии мы будем использовать, мы остановились на использовании сервера приложений JBoss, внешнего интерфейса Flex (с возможным развертыванием на настольных компьютерах с использованием Adobe AIR) и веб-сервисов для взаимодействия клиента и сервера.

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

Вот мои вопросы:

1. Каковы аргументы за или против EJB3 по сравнению со Spring?
   • Какие подводные камни меня могут ожидать в каждом случае?
   • Где я могу найти хорошую информацию о тестах?

Answer 1

Большой разницы между EJB3 и Spring в зависимости от производительности не будет.Мы выбрали Spring по следующим причинам (не упомянутым в вопросе):

• Spring направляет архитектуру в направлении, более легко поддерживающем модульное тестирование.Например, внедрите макет объекта DAO для модульного тестирования вашего бизнес-уровня или используйте объект Spring MockHttpRequest для модульного тестирования сервлета.Мы поддерживаем отдельную конфигурацию Spring для модульных тестов, которая позволяет нам изолировать тесты на определенных уровнях.
• Главным драйвером была совместимость.Если вам нужно поддерживать более одного сервера приложений (или в конечном итоге вы захотите перейти с JBoss на Glassfish и т. д.), вы, по сути, будете носить с собой свой контейнер (Spring), а не полагаться на совместимость между различными реализациями Спецификация EJB3.
• Spring позволяет выбирать технологии для сохранения, удаленного взаимодействия объектов и т. д.Например, мы также используем интерфейс Flex и протокол Hessian для связи между Flex и Spring.

Answer 2

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

Спор о модульном тестировании сейчас совершенно неактуален — EJB3 явно спроектирован так, чтобы его было легче тестировать.

Приведенный выше аргумент совместимости также не имеет значения:независимо от того, используете ли вы EJB3 или Spring, вы по-прежнему полагаетесь на сторонние реализации менеджеров транзакций, JMS и т. д.

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

Answer 3

Каковы аргументы за или против EJB3 по сравнению со Spring?Spring всегда внедряет инновации и учитывает ограничения реального мира.Spring предлагал простоту и элегантность серверов приложений Java 1.4 и не требовал версии спецификации J2EE, к которой никто не имел доступа в 2004–2006 годах.На данный момент это почти религиозные дебаты, в которые вы можете втянуться: Spring + абстракция + открытый исходный код против спецификаций Java Enterprise Edition (Java EE) 5.0.

Я думаю, весна дополняет больше, чем конкурирует со спецификациями Java EE.Поскольку функции, которые когда-то были уникальными для Spring, продолжают включаться в спецификацию, многие утверждают, что EJB 3 предлагает «достаточно хороший» набор функций для большинства внутренних бизнес-приложений.

Какие подводные камни меня могут ожидать в каждом случае?Если вы рассматриваете это как проблему персистентности (Spring+JPA) по сравнению с EJB3, вы действительно не делаете такого большого выбора.

Где я могу найти хорошую информацию о тестах?я не следил за результаты тестов Specj какое-то время, но какое-то время они были популярны.Кажется, что каждый поставщик (IBM, JBOSS, Oracle и Sun) все меньше и меньше заинтересован в наличии совместимого сервера.Списки сертифицированных поставщиков становятся все короче и короче по мере перехода от версий 1.3 к 1.4.1.5 Java Enterprise Edition.Я думаю, времена гигантских серверов, полностью соответствующих всем спецификациям, прошли.

Answer 4

Я определенно рекомендовал бы EJB3 весной.Мы обнаружили, что он более рационален, удобнее кодировать и лучше поддерживается.Раньше я использовал Spring и нашел его очень запутанным и не так хорошо документированным, как EJB3 (или JPA, я думаю, в конце концов).

1. Начиная с EJB3, вам больше не придется иметь дело с внешними файлами конфигурации, и для каждой таблицы базы данных можно аннотировать только один POJO.Этот POJO можно без проблем передать на ваш веб-уровень.Такие IDE, как Netbeans, могут даже автоматически генерировать для вас эти POJO.Сейчас мы использовали EJB3 в качестве серверной части для довольно большого количества крупномасштабных приложений и не заметили никаких проблем с производительностью.Ваши сеансовые компоненты можно легко представить в виде веб-сервисов, которые вы можете предоставить вашему интерфейсу Flex.Сессионные компоненты легко заблокировать на уровне метода или класса, чтобы при необходимости назначать роли и тому подобное.

Я не могу много говорить о весне, так как пробовала ее всего несколько недель.Но общее впечатление от этого места было очень плохим.Это не значит, что это плохая платформа, но наша команда пришла к выводу, что EJB3 лучше всего подходит для уровня сохраняемости/бизнеса.

Answer 5

Я склонен предпочитать Spring, а не EJB3, но я бы рекомендовал, какой бы подход вы ни выбрали, старайтесь придерживаться написания POJO и использовать стандартные аннотации, где это возможно, например аннотации JSR, такие как @PostConstruct, @PreDestroy и @Resource, которые работают как с EJB3, так и с EJB3. или Spring, чтобы вы могли выбрать любую платформу, которую вы предпочитаете.

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

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

Сессионные компоненты в основном сводятся к внедрению зависимостей и транзакциям;так что EJB3 и Spring в этом действительно похожи.Преимущество Spring заключается в улучшенном внедрении зависимостей и более удобных абстракциях для таких вещей, как JMS.

Answer 6

Раньше я использовал очень похожую архитектуру.Spring + Java 1.5 + Actionscript 2/3 в сочетании с Flex Data Services сделали кодирование очень простым (и увлекательным!)однако интерфейс Flex означает, что вам нужны достаточно мощные клиентские машины.

Answer 7

Что касается вашего вопроса:

Каковы аргументы за или против EJB3 по сравнению со Spring?

Предлагаю прочитать ответ экспертов: ОТВЕТ НА:СРАВНИТЕЛЬНЫЙ АНАЛИЗ EJB 3 И Spring, Марк Фишер.Прочтите комментарии, чтобы найти замечания Резы Рахмана (EJB 3.0).

Answer 8

Еще одним преимуществом Spring является то, что большинство других инструментов/фреймворков имеют лучшую поддержку интеграции с Spring, большинство из них также используют Spring внутри (например,activemq, Camel, CXF и т. д.).

Он также более зрелый, и в нем гораздо больше ресурсов (книг, статей, лучших практик и т. д.) и опытных разработчиков, чем для EJB3.

Answer 9

Я думаю, что EJB — это хорошая компонентная технология, но не очень хорошая платформа. Spring — лучшая платформа, доступная на сегодняшний день. Поэтому я должен рассматривать Spring как лучшую реализацию JEE в смысле структуры, и я рекомендую использовать Spring во всех проект, который дает нам возможность легко интегрироваться с любой технологией компонентов.