Xpoint
   [напомнить пароль]

Готовится к выпуску J2EE 5 (EJB 3.0)

Метки: [без меток]
[арх]
2006-02-23 19:23:52 [обр] Денис Имаев(219/273)[досье]
сообщение промодерировано

Поскольку среди посетителей форума много пользователей J2EE, рекомендую обратить внимание на готовящуюся к выпуску спецификацию J2EE 5, в особенности конечно EJB 3.0. Наконец-то двинулись в сторону упрощения и вразумления всего этого кошмара.

Особенно сильно IMHO :

  1. Использование аннотаций вместо нагромождения уродливых интерфейсов.

К примеру, EJB home, EJB object интерфейсы больше не нужны, не надо кучу кода, просто пишем в начале класса
@Stateless , @Statefull или @MessageDriven
и все этим будет сказано.

  1. Dependency injection для ресурсов. Идея, давно используемая в lightweight containers.

Реализация через те же аннотации - не надо использовать всякие look-ups по типу

   DataSource myDataSource;
   myDataSource= (DataSource) ctx.lookup("jdbc/MyDB");

пишем просто

   @Resource private DataSource myDataSource;

  1. Необязательность deployment descriptor
  1. Persistence Model - взамен Entity Beans (ну то есть дополняя их).

Стандартизован способ object-relational mapping, хотя лично я бы пока не пользовался этим. Лучше что-нибудь проверенное типа Hibernate.
Кроме того, есть всякие optimistic locking support - быстрее будет работать, если вы согласны на то, что транзакция fail под самый конец, но в огромном количестве задач данные все равно не пересекаются настолько.

спустя 1 час 7 минут [обр] Владимир Палант(253/4445)[досье]
Да, я уже работал с этим — как отдельный пакет EJB 3.0 можно уже использовать сравнительно давно. Кошмара под названием EJB 2.0 мне удалось избежать, может поэтому у меня сложилось такое отрицательное впечатление. Прогресс налицо, но все равно впечатление чего-то жутко тормозного, и вообще приходится все делать через неподходящее для того место.
спустя 2 минуты [обр] Денис Имаев(219/273)[досье]
Владимир Палант[досье] Я не сомневаюсь :) По мне, все это вообще страшная ересь, но они хоть пытаются что-то сделать...
спустя 1 месяц 23 дня [обр] Robinzon(12/14)[досье]
Владимир Палант[досье]Денис Имаев[досье]
чем вас так ejb задели?
или вы знаете какие-то альтернативы для построения
масштабируемых транзактно-ориентированных распределённых серверных приложений для предприятий?
спустя 6 дней [обр] Владимир Палант(253/4445)[досье]
Абсолютно ничем — ну разве что тем, что как раз для построения масштабируемых приложений EJB абсолютно не годятся. Любой сделанный "на коленке" framework с этой задачей справится лучше, без потугов на универсальность.
спустя 1 час 33 минуты [обр] 30-ый(59/584)[досье]

Странно слышать это от вас...

> любой сделанный "на коленке" framework

хм... может пример приведете? При упоминании "на-коленке-фреймвоков" мне сразу представляется PHP и все его поделки типа TYPO3 или Smarty. EJB по сравнению с подобными "шедеврами" - просто мечта.

Из достойных же framework'ов для Java мне на ум приходит только Hibernate, который во-первых далеко не покрывает всех функций EJB, а во-вторых появился добрых лет на пять позже...

спустя 54 минуты [обр] Владимир Палант(253/4445)[досье]
Я же сказал — "без потугов на универсальность". Специально заточенное под задачу решение, без излишков. Время, которое тратится на его разработку (не слишком, кстати, большое) с лихвой окупается, поскольку не нужно искать глюки в недрах EJB-фреймворка (которых предостаточно) и на порядок легче оптимизировать быстродействие приложения (что придется делать в любом случае, если решение реально должно быть масштабируемым). Конечно, это попахивает изобретением колеса, но в данном случае ИМХО оправдано.
спустя 4 минуты [обр] Владимир Палант(253/4445)[досье]
PS: Чтобы меня не поняли неправильно — я не против универсальных решений. Код нужно использовать заново, это правильно. Но нужно знать меру. Если решение получается настолько универсальным, что для его настроек нужно в несколько раз больше кода, чем для написания того же самого вообще без фреймворка — тут что-то не так.
Powered by POEM™ Engine Copyright © 2002-2005