Лучшие возможности EJB 3

Question

Сценарий

• Вы разработали веб-приложение с использованием EJB версии 3.
• Система развернута, доставлена ​​и используется заказчиком.

Если бы вам пришлось переписывать систему с нуля, вы бы снова использовали EJB?

Нет : Не отвечайте на этот вопрос, вместо этого ответьте .

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

Пусть ответ содержит только одну проблему. Это позволит другим читателям голосовать за лучшую функцию EJB.

Answer 1

Я думаю, это зависит от того, о какой версии EJB вы говорите. Давайте обсудим только две соответствующие (IMO) версии.

EJB 2.1 все еще может использоваться некоторыми людьми в устаревшей системе. Они действительно больше всего используются в качестве абстракции RPC. Они также предоставили элементарную систему ORM (объектно-реляционное отображение). И, как вы упомянули, поддержка транзакций предоставляется. Таким образом, если вы строите систему, в которой вы хотите обмениваться данными с удаленной системой, передавать объектно-ориентированные данные и делать это транзакционно, вы можете обнаружить, что EJB-компоненты того стоят. В противном случае, я бы сказал, держись подальше.

EJB 3.0, однако, был значительно улучшен. Он имеет все функции предыдущей версии, но делает это более простым способом. Он также предоставляет довольно простую инфраструктуру Inversion-Of-Control, не похожую на Spring, и довольно приличный ORM в форме JPA (Java Persistence API.) Я использовал EJB 3.0 и действительно наслаждался им. Вы могли бы поспорить за использование EJB 3.0 так же, как и для Spring, плюс в нем есть несколько более продвинутых или корпоративных функций.

Answer 2

Ну, это действительно зависит от того, о каких EJB мы говорим. Я бы сказал, что МБР все еще могут быть полезны даже сейчас. Для сущностных и сессионных компонентов вы наверняка найдете лучший подход. Возможно, одна особенность, которая мне все еще нравится в EJB, - это масштабируемость. Используя опцию «Удаленный», вы можете при необходимости развернуть EJB на разных серверах. Однако я не думаю, что это действительно необходимо, и я видел только один огромный проект, где он был действительно полезен.

Answer 3

Основная причина использования платформы Java Java - по определению. вам нужна платформа, которая решает проблемы параллелизма, доступности, управления транзакциями, обмена сообщениями и управления в полностью проверенной, совместимой и совместимой платформе. да, вы можете сделать все это самостоятельно, склеив целый ряд библиотек и поместив их поверх tomcat, но зачем тратить все это время на проверку и управление совместимостью и набором функций, когда вы можете писать на полностью проверенную платформу, поддерживающую стандарты. любой ee-контейнер ДОЛЖЕН передать tck, иначе он не может переносить псевдоним Java EE.

то, что разные люди говорят о «легком весе», «типах» ejbs и т. Д., Излишне. если вам не нужен набор функций платформы или гарантия полной внутренней совместимости ваших библиотек с левереджем, то ejb (он же платформа java ee) является излишним. но если вы действительно решаете проблему качества предприятия (см. первый абзац), то ejb и платформа java ee дадут вам то, что вам нужно.

Answer 4

Много работал в прошлом с EJB 2.1, рад оставить его позади.

Значение EJB остается верным для 3.0 и несет в себе симпатичную легковесную модель программирования. Управление транзакциями, параллелизм, управление версиями данных, управление состоянием - это нетривиальные проблемы, требующие правильного решения, и платформы Java EE продолжают отлично работать.

По общему признанию, я использую Hibernate и Seam для дальнейшего наращивания некоторых функций Java EE, поэтому я не совсем справедливо скажу, что EJB 3.0 сам по себе является Меккой. Однако я нахожу слишком много разработчиков, выбрасывающих пресловутого ребенка из воды в ванну, когда они полностью отказываются от Java и переходят на что-то более модное, например, Rails.

Seam представляет собой прекрасную клеевую среду, которая сохраняет усилия программиста на достаточно низком уровне. Также позволяет вам выбирать проект в зависимости от проекта, когда EJB имеет смысл по сравнению с POJO, БЕЗ необходимости менять стиль программирования.

Answer 5

Соглашение по конфигурации.

Стандартное поведение EJB 3 чаще всего желаемое. Я думаю, что основной проблемой в EJB 2.1 была необходимость в подробных файлах конфигурации, новая конфигурация на основе аннотаций решает большую часть этой проблемы.

Answer 6

Одна вещь, которая многих укушала при использовании EJB, или J2EE в целом, это зависимость от сервера приложений, на котором вы запускаете свои EJB. Сервер приложений, как правило, поддерживается для определенного набора выпусков операционной системы и версий JVM. Отсутствие исходного кода в значительной части среды выполнения также может стать проблемой.

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

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