EJB 3.1 или Spring 3. Когда что выбрать?

Для вашего варианта использования, когда приложение работает на одном сервере, а база данных — на другом, выбор между EJB и Spring не имеет значения. Каждая платформа поддерживает это, будь то приложение Java SE, простой контейнер сервлетов, такой как Tomcat или Jetty, PHP, Ruby on Rails или что-то еще.

Для этого вам не нужно никакого явного удаленного взаимодействия. Вы просто определяете источник данных, предоставляете URL-адрес, где находится ваш сервер БД, и все.

Тем не менее, и EJB, и Spring Beans упрощают работу с источниками данных. Они оба помогают вам определить источник данных, внедрить его в bean-компоненты и управлять связанными с ними транзакциями.

Из этих двух компонентов EJB (и Java EE в целом) является более легким и в большей степени придерживается принципа соглашения по сравнению с конфигурацией. Spring требует большей детализации, чтобы получить то же самое, и во многом зависит от XML-файлов, которые могут быстро стать очень большими и громоздкими. Обратная сторона медали заключается в том, что Spring может быть менее волшебным, и вы можете чувствовать себя более уверенно после того, как пропишете все, что хотите.

Другая проблема заключается в том, как разрабатываются EJB и Spring.

EJB бесплатен (как и бесплатное пиво), с открытым исходным кодом и не является собственностью. Существуют реализации EJB, созданные некоммерческими организациями (Apache), компаниями с открытым исходным кодом (Redhat/JBoss) и коммерческими предприятиями с закрытым исходным кодом (IBM). Лично я бы избегал последнего, но каждому свое.

Spring, с другой стороны, является бесплатным и открытым исходным кодом, но строго проприетарным. Существует только одна компания, производящая Spring, и это Springsource. Если вы не согласны с Родом, то вам не повезло. Это не обязательно плохо, но разница, о которой вы, возможно, захотите знать.

Делать все @Annotation всегда хорошо? конфигурация никогда не нужна?

Это бесконечный спор на самом деле. Некоторые утверждают, что XML трудно поддерживать, другие утверждают, что аннотации загрязняют в остальном чистую модель POJO.

Я думаю, что аннотирование bean-компонента как bean-компонента EJB без состояния (@Stateless) или объекта JPA (@Entity) более четко выполняется с использованием аннотаций. То же самое касается инъекций зависимостей @EJB или @Inject. С другой стороны, я предпочитаю, чтобы именованные запросы JPQL находились в XML-файлах, а не в аннотациях, а инъекции, представляющие чистые данные конфигурации (например, максимальное значение для чего-либо), также были в XML.

В Java EE каждая аннотация также может быть указана в XML. Если присутствуют и аннотация, и XML-эквивалент, XML имеет приоритет над аннотацией. Это делает очень удобным начать с аннотации для случая по умолчанию, но позже переопределить ее через XML для конкретного варианта использования.

Текущие предпочтения в Java EE, похоже, больше связаны с (простыми) аннотациями в сочетании с большим количеством соглашений по сравнению с конфигурацией.

Настоящий вопрос, который вы должны задать, это CDI/EJB или Spring.

Часто это не Spring против EJB, а Spring против Java EE. Сам EJB сравнивается со Spring Beans. Оба они являются своего рода управляемыми bean-компонентами, работающими внутри контейнера (контейнер EJB или контейнер Spring).

В целом эти две технологии довольно похожи. Реза Рахман провел отличное сравнение между ними некоторое время назад.

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

В среде EJB, когда развернут EAR ('E'enterprise' AR'chive), он может быть развернут с несколькими bean-компонентами EJB, каждый из которых может иметь определенную цель. Допустим, вы написали компонент для управления пользователями и другой компонент для управления продуктом. Возможно, однажды вы обнаружите, что ваши пользовательские сервисы намного превосходят сервисы доступа к вашим продуктам, и вы захотите переместить свой пользовательский компонент на другой сервер на другом компьютере. На самом деле это можно сделать во время выполнения без изменения кода. Bean-компоненты можно перемещать между серверами и базами данных, чтобы обеспечить кластеризацию и балансировку нагрузки/данных, не затрагивая ваших разработчиков или пользователей, поскольку большую часть этого можно настроить на уровне развертывания.

Еще одна причина для поддержки стандарта заключается в том, что он знает, что большинство крупных сторонних поставщиков, скорее всего, поддержат его, что приведет к меньшему количеству проблем при интеграции с новым стандартом/услугой/технологией – и давайте смотреть правде в глаза, они появляются как новые вкусы мороженого. И если он находится в публичной спецификации, новые стартапы или добрые разработчики могут создать версию с открытым исходным кодом.

http://www.onjava.com/pub/a/onjava/2005/06/29/spring-ejb3.html

Очень жаль, что даже самые умные дизайнеры или программисты не могут предсказать, какие из их функций могут или не могут быть приняты сообществом разработчиков, что является основной причиной раздувания программного обеспечения ... Java EE определенно это!

Выберите одно или другое, но не оба.

Лично я предпочитаю Весну. Я использовал в проектах с большим успехом в течение последних шести лет. Это так же надежно, как любое программное обеспечение.

Spring может работать с EJB, если вы решите использовать их в своем приложении, но я не думаю, что верно обратное.

Я бы рекомендовал отдельные физические машины для веб-серверов, серверов приложений и баз данных, если вы можете себе это позволить.

Spring может работать с несколькими вариантами удаленного взаимодействия, включая веб-службы SOAP и REST. Сравнение компонентов Spring с EJB выходит за рамки этого вопроса. Я не понимаю, какое это имеет отношение к вашей реализации. Если вы используете службы Spring POJO, они находятся в памяти, а не требуют другого сетевого перехода, такого как удаленные EJB. Вспомните закон Фаулера о распределенных объектах: «Не делайте этого». Вводите задержку только по уважительной причине.

EJB 3.1 является лучшим, хотя и является стандартом для приложений Java 6 EE.

Spring по-прежнему не поддерживает Java 6 CDI (сварка), а также во многом зависит от конфигурации XML. EJB 3.1 мощный и умный.

Я думаю, что Spring 3.1 не нуждается в настройке XML. У вас есть возможность использовать аннотации для конфигурации.

Я бы упомянул модульное тестирование здесь. В обычном веб-приложении (контроллер->сервис->данные->...->представление) EJB и Spring обеспечивают одинаковый результат, но Spring предлагает более простое тестирование.

По моему скромному опыту, то, как вы развиваетесь, отличается в нескольких аспектах:

• Юнит-тест (весенние победы). Весной это делается довольно прямолинейно, в то время как в ejb вы должны использовать Arqullian с ShrinkWrap (sic!), Который медленно работает на каждой сборке.
• Настойчивость (побеждает ejb). Весной вокруг этого идет борьба, т.е. гуглите "как автопроводить постоянство в прослушивателе сущностей" http://bit.ly/1P6u5WO< /а>
• Конфигурация (побеждает ejb). Как новичок, пришедший из ejb, я был удивлен роем аннотаций и файлов .xml.