Лучшие особенности EJB 3

Question

сценарию

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

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

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

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

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

Answer 1

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

Answer 2

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

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

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

Answer 3

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

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

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

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

Answer 4

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

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

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

Answer 5

Конвенция по конфигурации.

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

Answer 6

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

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