Должен ли я использовать 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 теперь заключается в том, что вы можете внедрять только в bean-компонент, поэтому вы можете в конечном итоге превратить компоненты в bean-компоненты, которые не должны быть.

Аргумент о модульном тестировании в настоящее время довольно неактуален - EJB3 разработан так, чтобы его было легче тестировать на модуле.

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

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

Answer 3

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

Я думаю, что Spring больше, чем конкурирует со спецификациями 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 в качестве бэкэнда для довольно большого количества крупномасштабных приложений и не заметили никаких проблем с производительностью. Ваш компонент Session Bean может быть легко представлен в виде веб-служб, которые вы можете использовать в своем интерфейсе Flex. Сессионные компоненты легко блокировать на уровне метода или класса для назначения ролей и тому подобного, если вам нужно.

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

Answer 5

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

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

Если вы хотите использовать внедрение перед запросом, например, в веб-приложении, вы можете обнаружить, что 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 И ВЕСНОЙ СРАВНИТЕЛЬНЫЙ АНАЛИЗ от Mark Fisher . Прочитайте комментарии, чтобы найти замечания Резы Рахмана (EJB 3.0).

Answer 8

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

Answer 9

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

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