Зачем в EJB использовать шаблон DAO если есть BMP или CMP компоненты?

Здравствуйте, Аноним, Вы писали:

А>Зачем в EJB использовать шаблон DAO если есть BMP или CMP компоненты?

BMP & CMP по моему таки и являются вариацией на теу DAO ?

Здравствуйте, Аноним, Вы писали:

А>Зачем в EJB использовать шаблон DAO если есть BMP или CMP компоненты?
А с чего вы решили что в EJB нужно использовать DAO, если все делать с BMP и CMP?

Здравствуйте, frёёm, Вы писали:

ёё>Здравствуйте, Аноним, Вы писали:

А>>Зачем в EJB использовать шаблон DAO если есть BMP или CMP компоненты?

ёё>BMP & CMP по моему таки и являются вариацией на теу DAO ?

Т.е. по сути BMP & CMP это и есть реализация шаблона DAO?

Здравствуйте, Аноним, Вы писали:

А>Т.е. по сути BMP & CMP это и есть реализация шаблона DAO?

Развёрнутый ответ на поврос.

В картце:
Одна из...только странная и кривая, размаззанная по Home и Remote интефейсу.

Использование нормальной DAO с интефейсами, и несколькими реализациями получаемыми через фабрику:
— разгружает entity бины от ненужной логики работы с данными.
— разделяет бизнес логику и доступ к данным
— делает bmp бины более переносимыми, дасточно подложить под них инной DAO и не переписывать все методы доступа, модификации данных.
реализация DAO для CMP бесмысленна, поскольку там персистентность реализуется не програмистом и контейнером

Здравствуйте, frёёm, Вы писали:


ёё>Использование нормальной DAO с интефейсами, и несколькими реализациями получаемыми через фабрику:
ёё>- разгружает entity бины от ненужной логики работы с данными.

Т.е. лучше самому все реализовать как в patter4.pdf в BMP ?

Здравствуйте, _me_, Вы писали:

__>Т.е. лучше самому все реализовать как в patter4.pdf в BMP ?

В серьёзном комерческом продукте (странно писать что-то иное с применением ejb 2) да...

С другой стороны если писать сейчас что-то новое но вероятно имеет смысл обратить взор на ejb3.
Там нету понятий cmp, bmp, вместо них обычные pojo и jpa.
Соответственно и эта проблема там не актуальна...

А то и вообще spring+...orm ?(я к сожалению не знаю можно ли spring привязать к jpa, руками их не щупал )

Здравствуйте, _me_, Вы писали:

__>Здравствуйте, frёёm, Вы писали:


ёё>>Использование нормальной DAO с интефейсами, и несколькими реализациями получаемыми через фабрику:
ёё>>- разгружает entity бины от ненужной логики работы с данными.


__>Т.е. лучше самому все реализовать как в patter4.pdf в BMP ?


BMP лучше не использовать. Используй DAO без всяких мучений.

__>>Т.е. лучше самому все реализовать как в patter4.pdf в BMP ?


А>BMP лучше не использовать. Используй DAO без всяких мучений.

Ок, а тип EJB компоненты какой использовать? сорри за глупый вопрос, но тоже только начал изучать...

Здравствуйте, _me_, Вы писали:

__>Ок, а тип EJB компоненты какой использовать? сорри за глупый вопрос, но тоже только начал изучать...
А зачем себе голову глупостями забивать? Spring + Hibernate — наше всё.

__>>Ок, а тип EJB компоненты какой использовать? сорри за глупый вопрос, но тоже только начал изучать...
B>А зачем себе голову глупостями забивать? Spring + Hibernate — наше всё.

Только при этом нужно помнить что EJB (из коробки) это гораздо больше чем просто DAO или Spring + ORM.

Здравствуйте, frёёm, Вы писали:

ёё>Только при этом нужно помнить что EJB (из коробки) это гораздо больше чем просто DAO или Spring + ORM.

Я б сказал, что это ejb гораздо меньше, чем spring + orm.

Здравствуйте, denis.zhdanov, Вы писали:

DZ>Я б сказал, что это ejb гораздо меньше, чем spring + orm.

Раскроете мысль ?

Я имел в виду что, ejb кроме всего прочего поддерживает message driven модель, распределённость и кластеризацию.

Здравствуйте, frёёm, Вы писали:

ёё>Раскроете мысль ?

ёё>Я имел в виду что, ejb кроме всего прочего поддерживает message driven модель, распределённость и кластеризацию.

1. jms != ejb, ejb только предлагает message consumer в виде отдельного типа бинов. Альтернатива спринга — MDP (message-driven pojos);
   
2. Remoting and web services using Spring;
   
3. Кластеризация не формализована в спецификации ejb, это фишка апп-сервера. В случае использования спринга тоже можно заиспользовать third-party apps;

Здравствуйте, _me_, Вы писали:

__>>>Т.е. лучше самому все реализовать как в patter4.pdf в BMP ?


А>>BMP лучше не использовать. Используй DAO без всяких мучений.

__>Ок, а тип EJB компоненты какой использовать? сорри за глупый вопрос, но тоже только начал изучать...
Можете себе сделать фасад из Stateless Session Bean с методами, которые делают переадресацию к вашему DAO.

Здравствуйте, denis.zhdanov, Вы писали:


DZ>

DZ>
1. jms != ejb, ejb только предлагает message consumer в виде отдельного типа бинов. Альтернатива спринга — MDP (message-driven pojos);
   DZ>
2. Remoting and web services using Spring;
   DZ>
3. Кластеризация не формализована в спецификации ejb, это фишка апп-сервера. В случае использования спринга тоже можно заиспользовать third-party apps;
   DZ>

Я на самом деле в спринге не силён...
Не подскажешь сторонних third-party apps для кластеризации ?

Здравствуйте, frёёm, Вы писали:

ёё>Я на самом деле в спринге не силён...
ёё>Не подскажешь сторонних third-party apps для кластеризации ?

здесь

Здравствуйте, frёёm, Вы писали:

ёё>Только при этом нужно помнить что EJB (из коробки) это гораздо больше чем просто DAO или Spring + ORM.
Складывается очучение, что ты последний год форум не читал. Как верно заметили выше J2EE != EJB

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, frёёm, Вы писали:

ёё>>Только при этом нужно помнить что EJB (из коробки) это гораздо больше чем просто DAO или Spring + ORM.
B>Складывается очучение, что ты последний год форум не читал. Как верно заметили выше J2EE != EJB

Я знаю что j2ee != ejb
Но честно говоря не вижу в своей фразе противоречащих утверждений

Что я не так сказал ?
То что обязательная кластеризация не является частью спецификации ejb я не знал, вот только начал читать спеку по ejb3.
Но реально, я не знаю не одного ejb2.1 контейнера не поддреживающего кластеризацию

Здравствуйте, denis.zhdanov, Вы писали:

DZ>здесь
И JBoss treecache, эти двое на пару вроде бы самые перспективные.

Здравствуйте, Blazkowicz, Вы писали:

B>Здравствуйте, denis.zhdanov, Вы писали:

DZ>>здесь
B>И JBoss treecache, эти двое на пару вроде бы самые перспективные.

А у меня вот сходу ещё такой возник вопрос:
Я на сколько понял и treecache & terracota это распределённые кеши ?

Я когда говорил о кластеризации имел в виду паралельное испольнение скажем, SLSB на кластерах, или просто
многопроцессорной машине ?

Известны какие то варианты как добится того же от spring'а ?

Здравствуйте, frёёm, Вы писали:

ёё>А у меня вот сходу ещё такой возник вопрос:
ёё>Я на сколько понял и treecache & terracota это распределённые кеши ?
terracota даже нечто большее.

ёё>Я когда говорил о кластеризации имел в виду паралельное испольнение скажем, SLSB на кластерах, или просто
ёё>многопроцессорной машине ?
Эээ, с многопроцессоными вопроса не понял. А в чем сложность-то? Запускаешь аппликуху на двух нодах, вот бины и работают параллельно. В чем суть вопроса?

ёё>А то и вообще spring+...orm ?(я к сожалению не знаю можно ли spring привязать к jpa, руками их не щупал )
Можно. Только JPA довольно простенькое API — сильно не хватает, например, хибернейтовских критериев

Здравствуйте, Blazkowicz, Вы писали:

B>Эээ, с многопроцессоными вопроса не понял. А в чем сложность-то? Запускаешь аппликуху на двух нодах, вот бины и работают параллельно. В чем суть вопроса?

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

вопрос про многопроцессоры он сосбтвенно про то и был,
если у нас одна машина, на которой 4 процессора.
То по идее если развернуть на машине ejb приложение, оно будет исполнятся там оптимально
используя мультитрединг.

А в случае спринг приложения наверно придётся делать каике-то хитрые движухи, если их
вообще можно зделать ? и какие ?

В случае кластеров ejb приложение будет пооддерживать распределённые транзакции между этими кластерами.
Я не знаю сможет ли их поддерживать terracota, раз уж это нечто более, чем распределённый кеш ?
может какие то другие фреймворки ?

Здравствуйте, frёёm, Вы писали:

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

ёё>вопрос про многопроцессоры он сосбтвенно про то и был,
ёё>если у нас одна машина, на которой 4 процессора.
ёё>То по идее если развернуть на машине ejb приложение, оно будет исполнятся там оптимально
ёё>используя мультитрединг.
Это все сугубо упирается в реализацию JVM и операционную систему. К EJB обратно никакого отношения не имеет.


ёё>А в случае спринг приложения наверно придётся делать каике-то хитрые движухи, если их
ёё>вообще можно зделать ? и какие ?
Эка у вас фантазия богатая. Хитрая движуха это случайно не new Thread().start()?

ёё>В случае кластеров ejb приложение будет пооддерживать распределённые транзакции между этими кластерами.
Менеджер распределенных транзакций прикручивается к Spring без проблема. Менеджер, поставляется вендором сервера приложений.

Здравствуйте, Blazkowicz, Вы писали:

B>Сервлеты тоже свободно без лишнизх усилий работают в многопоточной среде. Это никак не заслуга EJB.
Да сервлеты работают без лишних усилий потому что у них есть среда (сервлет контейнер) которая поддерживает для них многопоточность.

B>Это все сугубо упирается в реализацию JVM и операционную систему. К EJB обратно никакого отношения не имеет.
Мне казалось что ejb предоставляет подобную среду своим компонентам, и я как-то не думал, некогда, что это может упираться в JVM & OS.
Да возможно в случае однозадочной OS например =)) это очевидно...
Но в иных случаях...
Ты не мог бы если не лень пояснить на примерах ?

B>Эка у вас фантазия богатая. Хитрая движуха это случайно не new Thread().start()?
В самом простом случае да...
Собственно наверное что-то похожее работает и в сервлет контейнерах (тот же тредпул).
Кроме того должен быть какой то дескриптор развёртывания, где бы указывалось хотя бы количество процессоров на машине...
ну и какие то инные параметры приложения.
Spring по моему не предоставляет такого функционала из коробки ?
Это вероятно придётся реализовывать самому ? или и на этот случай что-то есть...
Понятно что это не самая не выполнимая задача, но всё же...

Здравствуйте, frёёm, Вы писали:

B>>Сервлеты тоже свободно без лишнизх усилий работают в многопоточной среде. Это никак не заслуга EJB.
ёё>Да сервлеты работают без лишних усилий потому что у них есть среда (сервлет контейнер) которая поддерживает для них многопоточность.

С помощью Spring можно к логике прикрутить любой многопоточный интерфейс, будь-то сервлеты, MQ, Socket Server или что ещё. Подобные фасады занимаются в частности тем что создают разные потоки под разные запросы извне.
Эти потоки работают через любые POJO. В чем тут сакраментальное превосходство EJB?

ёё>Ты не мог бы если не лень пояснить на примерах ?
Легко, дай мне пожалуйста EJB deployment descriptor, где можно конфигурять сколько CPU используется бином.

ёё>Spring по моему не предоставляет такого функционала из коробки ?
ёё>Это вероятно придётся реализовывать самому ? или и на этот случай что-то есть...
ёё>Понятно что это не самая не выполнимая задача, но всё же...
У меня радикально другие представления о EJB. Можно плз, ссылок по теме EJB работает на многопроцессорной машине лучше чем что-бы то либо?

Здравствуйте, Blazkowicz, Вы писали:


B>С помощью Spring можно к логике прикрутить любой многопоточный интерфейс, будь-то сервлеты, MQ, Socket Server или что ещё.
B>Подобные фасады занимаются в частности тем что создают разные потоки под разные запросы извне.
Я же говорил, я не имею обширного опыта работы со spring'ом. По этому по многим вопросам это пока что для меня тёмный лес.
То есть иммется в виду что мы не только из сервлетов используем spring как контейнер для entity, но и сервлеты из спринга
в качестве "поточного фреймворка", что-то в этом духе ?

ёё>>Ты не мог бы если не лень пояснить на примерах ?
B>Легко, дай мне пожалуйста EJB deployment descriptor, где можно конфигурять сколько CPU используется бином.
Ну зачем же так...например при утановке ejb контайнера или сервера приложений наверняка эта информацию откуда-то берётся,
или системой инсталяции или прописывается инженером ?
(это всего лишь мои догадки).

ёё>>Spring по моему не предоставляет такого функционала из коробки ?
ёё>>Это вероятно придётся реализовывать самому ? или и на этот случай что-то есть...
ёё>>Понятно что это не самая не выполнимая задача, но всё же...
B>У меня радикально другие представления о EJB. Можно плз, ссылок по теме EJB работает на многопроцессорной машине лучше чем что-бы то либо?
Я не говорил что он работает лучше чем чтобы то ни було.
Просто мне трудно поверить, ejb такая дура...а тут какой то spring, довольно простая в своей сути штука.
Понятно что на него можно навесить наверное всё что угодно, вопрос в общем то был в том есть ли у спринга
заменители для функционала предоставляемого ejb'ями.
Похоже что есть...
И насколько сложно их настроить для работы с друг другом...
Похоже что не очень...

Спасиба, просвятил

Здравствуйте, frёёm, Вы писали:

ёё>Я же говорил, я не имею обширного опыта работы со spring'ом. По этому по многим вопросам это пока что для меня тёмный лес.
Не сочти за грубость, но мне кажется что и с EJB у тебя опыт не на много больше.

ёё>Ну зачем же так...например при утановке ejb контайнера или сервера приложений наверняка эта информацию откуда-то берётся, или системой инсталяции или прописывается инженером ?
ёё>(это всего лишь мои догадки).
Это всего лишь твои догадки. Скажи как можно выдавать догадки за аргумент?

ёё>Просто мне трудно поверить, ejb такая дура...
Смотри книжки:
"Expert One-on-One J2EE Development without EJB"
"Better, Faster, Lighter Java"

ёё>а тут какой то spring, довольно простая в своей сути штука.
ёё>Понятно что на него можно навесить наверное всё что угодно, вопрос в общем то был в том есть ли у спринга
ёё>заменители для функционала предоставляемого ejb'ями.
Вопрос не только в Spring. Spring всего лишь средство интеграции. Но с помощью ряда opensource решений этим средством интегрируется все что заменяет EJB на раз.
Spring не является прямым аналогом EJB.

Здравствуйте, frёёm, Вы писали:

ёё>я где-то, когда-то читал, что приложение написаное в соответствии с ejb и исполняющееся в ejb контейнере
ёё>может свободно, без лишних усилий работать в многопоточной среде.
Ага, конечно. Кластеризацию stateless session beans оно тебе, может, и обеспечит без лишних усилий. Но под все остальное надо заранее проектировать и тестировать, прозрачная кластеризация — это вообще утопия.

В Spring'е все аналогично, но проще в использовании.

ёё>То по идее если развернуть на машине ejb приложение, оно будет исполнятся там оптимально
ёё>используя мультитрединг.
Аналогично со Spring'ом — используй оптимальные для задачи конфигурации фабрик.

ёё>А в случае спринг приложения наверно придётся делать каике-то хитрые движухи, если их
ёё>вообще можно зделать ? и какие ?
Для простого использования пулов потоков — все есть в самом Spring'е, ничего подключать не надо.

ёё>В случае кластеров ejb приложение будет пооддерживать распределённые транзакции между этими кластерами.
Ты неправильно понимаешь суть понятия "распределенная транзакция". Это не транзакция, работающая на кластере, а транзакция, в которой участвуют два или более источника. Например, база данных и JMS одновременно. Распределенных транзакций надо всеми силами избегать, в том числе и на кластерах.

ёё>Я не знаю сможет ли их поддерживать terracota, раз уж это нечто более, чем распределённый кеш ?
ёё>может какие то другие фреймворки ?
Terracotta — это простой метод организовать кластер. Есть и другие решения: GigaSpaces, Coherence, GridGain, ... — у каждого есть свои достоинства и недостатки. И естественно, все они интегрируются со Spring'ом. Это сейчас обязательное условие для нормальных продуктов

Здравствуйте, frёёm, Вы писали:

ёё>Я же говорил, я не имею обширного опыта работы со spring'ом. По этому по многим вопросам это пока что для меня тёмный лес.
ёё>То есть иммется в виду что мы не только из сервлетов используем spring как контейнер для entity, но и сервлеты из спринга
ёё>в качестве "поточного фреймворка", что-то в этом духе ?
Примерно так.

ёё>Ну зачем же так...например при утановке ejb контайнера или сервера приложений наверняка эта информацию откуда-то берётся,
ёё>или системой инсталяции или прописывается инженером ?
ёё>(это всего лишь мои догадки).
Это _может_ прописываться в отдельных appserver-specific конфигах.

ёё>Просто мне трудно поверить, ejb такая дура...а тут какой то spring, довольно простая в своей сути штука.
Тут как раз: "Краткость — сестра таланта".

ёё>Понятно что на него можно навесить наверное всё что угодно, вопрос в общем то был в том есть ли у спринга
ёё>заменители для функционала предоставляемого ejb'ями.
Да, _все_ возможности есть. Абсолютно все.

ёё>Похоже что есть...
ёё>И насколько сложно их настроить для работы с друг другом...
ёё>Похоже что не очень...
Я лично переместил сложное приложение с EJB3 (там использовалось JMS, JPA, JNDI и JMX) на Spring примерно за 3 дня. При этом, большая часть работы заключалась в cut&paste в конфиге. Работать оно после этого стало только лучше.

Здравствуйте, frёёm, Вы писали:

ёё>Здравствуйте, Blazkowicz, Вы писали:

B>>Здравствуйте, denis.zhdanov, Вы писали:

DZ>>>здесь
B>>И JBoss treecache, эти двое на пару вроде бы самые перспективные.

ёё>А у меня вот сходу ещё такой возник вопрос:
ёё>Я на сколько понял и treecache & terracota это распределённые кеши ?

ёё>Я когда говорил о кластеризации имел в виду паралельное испольнение скажем, SLSB на кластерах, или просто
ёё>многопроцессорной машине ?

ёё>Известны какие то варианты как добится того же от spring'а ?

Сравнивать Терракоту с JB cache не стоит Терракота это пример виртуализации (объединения нескольких VM в одну виртуальную) во всеми проблемами конфигурации и выволенения вашего кода на разных VM ну а JB cache это в чистую data cache работающий на JGroups и имеющий tree like структуру позволяющую перемещать куски дерева вместо кучи данных.