Вопрос по java-ee, java, ejb-3.0 – Лучшие возможности EJB 3

21

Сценарий

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

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

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

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

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

Удручает то, что очень многие разработчики (вынуждены) использовать EJB-компоненты, но ниже нет ни одного ответа, в котором перечислены реальные и решенные проблемы. Arne Evertsson

Ваш Ответ

6   ответов
5

это зависит от того, о какой версии 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, плюс в нем есть несколько более продвинутых или корпоративных функций.

латформа IoC / DI от Spring гораздо более универсальна и мощна, чем EJB3, и включает в себя множество других функций, например, AOP. Я не говорю, что EJB3 плох, но характеризовать его как содержащий более простой расширенный набор функций Spring не совсем точн Kevin Wong
Я сейчас в центре SCBCD для ejb3.0. Выглядит вполне нормально svrist
EJB3 включает AOP PEELY
2

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

1

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

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

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

1

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

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

По моему опыту, вам вряд ли когда-нибудь понадобятся все эти функции. И когда вам нужна одна или две функции, есть более простые и лучшие альтернативы. И кстати, то же самое относится и к весне, которая также перегружена. Arne Evertsson
0

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

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

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

0

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

Похожие вопросы