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

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

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

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

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

ОТВЕТЫ

Ответ 1

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

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

Ответ 2

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

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

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

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

Ответ 3

Каковы аргументы для или против EJB3 vs Spring? 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 benchmark results на некоторое время, но они были популярны некоторое время. Кажется, что каждый поставщик (IBM, JBOSS, Oracle и Sun) все меньше и меньше интересуется наличием совместимого сервера. Списки получают Короче и короче сертифицированных поставщиков, начиная с 1.3, 1.4. 1.5 Java Enterprise Edition. Я думаю, что дни гигантского сервера, полностью совместимые со всеми спецификациями, закончились.

Ответ 4

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

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

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

Ответ 5

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

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

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

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

Ответ 6

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

Ответ 8

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

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

Ответ 9

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