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

<p>моя команда разрабатывает новый сервис-ориентированный продукт с веб-интерфейсом. при обсуждении того, какие технологии мы будем использовать, мы остановились на работе сервера приложений jboss, веб-интерфейса flex (с возможностью развертывания на рабочем столе с использованием adobe air) и веб-служб для взаимодействия клиента и сервера.</p><p>мы зашли в тупик, когда речь заходит о том, какую серверную технологию использовать для нашей бизнес-логики. главный аргумент - между ejb3 и spring, при этом нашими основными проблемами являются масштабируемость и производительность, а также удобство сопровождения базы кода.</p><p>вот мои вопросы:</p><ol> <li>каковы аргументы за или против ejb3 против spring? <ul> <li>какие подводные камни можно ожидать с каждым?</li> <li>где я могу найти хорошую информацию о тестах?</li> </ul> </li> </ol>

<p>там не будет большой разницы между ejb3 и spring на основе производительности. мы выбрали spring по следующим причинам (не упомянутым в вопросе):</p><ul> <li>spring направляет архитектуру в направлении, которое более легко поддерживает модульное тестирование. например, вставьте фиктивный объект dao для модульного тестирования вашего бизнес-уровня или используйте объект spring mockhttprequest для модульного тестирования сервлета. мы поддерживаем отдельную конфигурацию spring для модульных тестов, которая позволяет нам изолировать тесты для определенных уровней.</li> <li>основным драйвером была совместимость. если вам нужно поддерживать более одного сервера приложений (или, в конечном итоге, вы захотите перейти с jboss на glassfish и т.д.), вы, по сути, будете нести свой контейнер (spring) с собой, а не полагаться на совместимость между различными реализациями спецификация ejb3.</li> <li>spring позволяет выбирать технологии для persistence, удаленного взаимодействия объектов и т.д. например, мы также используем интерфейс flex и используем протокол hessian для связи между flex и spring.</li> </ul>

<p>ясно, что разрыв между ejb3 и spring намного меньше, чем был. тем не менее, один из недостатков ejb3 теперь заключается в том, что вы можете внедрять только в bean-компонент, поэтому вы можете в конечном итоге превратить компоненты в bean-компоненты, которые не нужны.</p><p>аргумент о модульном тестировании в настоящее время довольно неактуален - ejb3 явно спроектирован так, чтобы его было легче тестировать.</p><p>приведенный выше аргумент совместимости также не имеет значения: используете ли вы ejb3 или spring, вы все еще зависите от сторонних реализаций менеджеров транзакций, jms и т.д.</p><p>однако для меня это поддержка со стороны сообщества. работая над проектом ejb3 в прошлом году, просто было мало людей, которые использовали его и говорили о своих проблемах. spring, правильно или неправильно, чрезвычайно распространен, особенно на предприятии, и это облегчает поиск человека, у которого есть та же проблема, которую вы пытаетесь решить.</p>

<p><strong> каковы аргументы за или против ejb3 против spring? </strong> spring всегда вводит новшества и признает ограничения реального мира. spring предлагал простоту и элегантность для серверов приложений java 1.4 и не требовал версии спецификации j2ee, к которой никто не имел доступа в 2004 - 2006 годах. на данный момент это почти религиозная дискуссия, которую вы могут быть втянуты в - spring + abstraction + open-source против java спецификации enterprise edition (java ee) 5.0.</p><p>я думаю, что spring <strong> дополняет больше, чем конкурирует </strong> со спецификациями java ee. поскольку функции, которые когда-то были уникальными для spring, продолжают включаться в спецификацию, многие будут утверждать, что ejb 3 предлагает "достаточно хороший" набор функций для большинства внутренних бизнес-приложений.</p><p><strong> какие подводные камни можно ожидать с каждой из них? </strong> если вы рассматриваете это как проблему постоянства (spring + jpa) по сравнению с ejb3, вы на самом деле не делаете такой большой выбор.</p><p><strong> где найти хорошую информацию о бенчмарке? </strong> я некоторое время не следил за <a href="http://www.spec.org/jappserver2004/results/jappserver2004.html">результатами теста specj</a> , но они были популярны для какое-то время. кажется, что каждый поставщик (ibm, jboss, oracle и sun) все меньше и меньше интересуется наличием совместимого сервера. списки становятся короче и короче сертифицированных поставщиков по мере того, как вы переходите от 1.3, 1.4. 1,5 java enterprise edition. я думаю, что времена гигантского сервера, который полностью соответствует всем спецификациям, прошли.</p>

<p>я определенно рекомендую ejb3 на весну. мы находим, что он более оптимизирован, более приятен для кодирования и лучше поддерживается. в прошлом я использовал spring и обнаружил, что он очень запутанный, и не так хорошо документирован, как ejb3 (или jpa, я думаю, в конце дня)</p><ol> <li>начиная с ejb3 вам больше не нужно иметь дело с внешними конфигурационными файлами, и есть только один pojo, который вы аннотируете для каждой таблицы базы данных. этот pojo может быть без проблем передан на ваш веб-уровень. ide, такие как netbeans, могут даже автоматически генерировать эти pojo для вас. мы использовали ejb3 в качестве бэкэнда для довольно большого количества крупномасштабных приложений и не заметили никаких проблем с производительностью. ваш компонент session bean может быть легко представлен в виде веб-служб, которые вы можете использовать в своем интерфейсе flex. сессионные компоненты легко блокировать на уровне метода или класса для назначения ролей и тому подобного, если вам это нужно.</li> </ol><p>я не могу так много говорить о весне, так как пробовал всего несколько недель. но мое общее впечатление об этом было очень плохим. это не означает, что это плохая структура, но наша команда нашла ejb3 лучшим для уровня персистентности/бизнеса.</p>

<p>я склонен предпочесть spring над ejb3, но моя рекомендация будет заключаться в том, какой подход вы выберете, попробуйте придерживаться написания pojo и, где возможно, использовать стандартные аннотации, такие как аннотации jsr, такие как @postconstruct, @predestroy и @resource, которые работают с обоими ejb3 или весна, чтобы вы могли выбрать любой каркас, который вы предпочитаете.</p><p>например вы можете выбрать какой-нибудь проект, чтобы использовать guice вместо ioc.</p><p>если вы хотите использовать внедрение перед запросом, например, в веб-приложении, вы можете обнаружить, что guice немного быстрее для внедрения зависимостей, чем spring.</p><p>сессионные компоненты в основном сводятся к внедрению зависимостей и транзакциям; так что ejb3 и spring действительно похожи на это. где у spring edge есть лучшее внедрение зависимости и более приятные абстракции для таких вещей, как jms</p>

<p>я использовал очень похожую архитектуру в прошлом. spring + java 1.5 + actionscript 2/3 в сочетании с flex data services сделали все это очень простым (и увлекательным!) для написания кода. тем не менее, внешний интерфейс flex означает, что вам нужны достаточно мощные клиентские машины.</p>

<p>по поводу вашего вопроса:</p><blockquote> <p>каковы аргументы за или против ejb3 против spring?</p> </blockquote><p>я предлагаю прочитать ответ экспертов: <a href="http://blog.springsource.org/2007/11/09/a-response-to-ejb-3-and-spring-comparative-analysis/">ответ на: ejb 3 и сравнительный анализ весны марком фишером</a> . прочитайте комментарии, чтобы найти замечания резы рахмана (ejb 3.0).</p>

<p>еще одна вещь в пользу spring - это то, что большинство других инструментов/фреймворков имеют лучшую поддержку для интеграции с пружиной, большинство из них также используют spring внутри (например, activemq, camel, cxf и т.д.).</p><p>он также более зрелый, и в нем гораздо больше ресурсов (книг, статей, лучших практик и т.д.) и опытных разработчиков, чем для ejb3.</p>