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

Question

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

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

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

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

Answer 1

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

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

Answer 5

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

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

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

Сессионные бобы в основном сводятся к инъекциям и транзакциям зависимости; поэтому EJB3 и Spring похожи на это похоже. Там, где весна имеет преимущество, более эффективная инъекция и более удобные абстракции для таких вещей, как JMS

Answer 6

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

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

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

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

Answer 7

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

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

Answer 8

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

Answer 9

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

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

Предлагаю прочитать ответ от экспертов: A RESPONSE TO: EJB 3 AND SPRING COMPARATIVE ANALYSIS by Mark Fisher. Прочтите комментарии, чтобы найти замечания Резы Рахман (EJB 3.0).