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

Ответ 1

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

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

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

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

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

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

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

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

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

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

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

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

Ответ 2

Реальный вопрос, который вы должны задать: CDI/EJB или Spring

Ответ 3

Это часто не Spring vs EJB, а Spring против Java EE. Сам EJB сравнивается с Spring Beans. Оба они являются своего рода управляемым beans, запущенным внутри контейнера (контейнер EJB и Spring).

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

Ответ 4

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

В среде EJB, когда развертывается EAR ( "E'nterprise" AR'chive), он может быть развернут с несколькими EJB beans, каждый из которых может иметь определенную цель. Скажем, вы написали bean для управления пользователями и еще один bean для управления продуктом. Возможно, однажды вы обнаружите, что ваши пользовательские сервисы превышают ваши службы доступа к продуктам, и вы хотите переместить своего пользователя bean на другой сервер на другой машине. Это можно сделать во время выполнения без изменения кода. beans может перемещаться между серверами и базами данных, чтобы сочетать кластеризацию и загрузку/балансировку данных, не затрагивая ваших разработчиков или ваших пользователей, поскольку большинство из них можно настроить на уровне развертывания.

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

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

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

Ответ 5

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

Мои личные предпочтения Spring. Я использовал проекты с большим успехом последние шесть лет. Он прочен, как и любое программное обеспечение.

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

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

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

Ответ 6

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

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

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

Ответ 7

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

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

• Unit test (spring выигрывает). В Spring все сделано довольно быстро, в то время как в ejb вам нужно использовать Arqullian с ShrinkWrap (sic!), Который медленно запускается на каждой сборке.
• Стойкость (побеждает ejb). В Spring есть борьба вокруг него, т.е. Google "как автоуверить настойчивость в слушателе сущностей" http://bit.ly/1P6u5WO
• Конфигурация (выигрыши ejb). Поскольку новичок, пришедший на Spring из ejb, меня удивил рой аннотаций и файлов .xml.