Я бы сказал, что ближе к Velocity/Webmacro, синтаксис языка похож.

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

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

Тяжеловесная, но для определённых задач - самое то.
Это как сравнить самолёт и танк.

Конечно, возиться с EJB2.1 - это своего рода подвиг  Но уже есть 3.0 .... 

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

еджиби надо пользовать там, для чего были задуманы. Есссно, вэб - тоже в своей нише.

чтобы не быть голословным, обратимся к официальным источнегам  Вообще, технология бинов, в том числе и энтерпрайз, по большому счету, нужна для разработки API транспортного уровня бизнеслогики. Использование бинов дает дополнтельный уровень абстракций, т.е. я рисую нужные, скажем, энтити бины, пишу логику работы между этими бинами, скажем, на сейшен бинах, пакую эту логику и все - я автоматом получаю: персистанс - раз, тразакции - два, CORBA - три, модульность - четыре, etc. etc. etc.. Я пишу юниттесты, которые будут тестить мой жарник и усе. Все, теперь я отдаю это джарник вебщикам, которые как их душе угодно делают к этой бизнеслогике обертку, хоть на вебе, хоть на стендэлоне, хоть вебсервисы прикручивают. Пофик. Красотисча  В тьюториле, кстати, очень подробно в овервью расписано про Development Roles. Моя позиция - надо пользоваться тем, что дают контейнеры как можно в большей мере. Потом ведь будут появляться проблемы как в соседних топиках - как сделать кластер, да легко - на еджебях, которые изначально проектировались под распределенные приложения, даже переписывать ничего не придется. Перенастраивай контейнеры и усе. Проблемы коммуникации между различными приложениями, которые можно бы было попробовать решить посредством Resource Adapter Modules... вобсчем, что-то я увлекся, потводя итог всему напечатанному, выбор технологий сильно зависит от преследуемых целей. Серьезное приложение только на вебконтейнере не вытянешь, может вообще проще оставить часть кода на PHP и пустить жабу в тандеме с апачем, так народ тоже частенько делает... 

Это сообщение отредактировал(а) y3u - 4.10.2006, 22:07

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

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

Просто любопытно.

лично я в данный момент не делаю ни как  Мы все еще сидим на старых еджебях и будем сидеть еще довольно долго. И все EJB уже давно протестированы, "старцы" вещали, что делали с помощью http://www.junitee.org/. Я просто описал ситуацию, которую хотел бы видеть в идеале  с юнит тестами, действительно, что-то я по горячился, но можно найти како-нить удобный техпроцесс...

Очент приятно услышать честный ответ 

Я ведь неспроста задал вопрос про юнит-тесты. Это одна из причин, по которым я в свое время отказался от идеи юзать EJB. И с большим облегчением отправил на свалку истории то, что уже успел к тому времени наваять. Позднее я нашел очень толковые рассуждения на эту тему у Рода Джонсона.в его J2EE Development Without EJB.

Не исключаю, что в EJB 3.0 ситуация малость улучшилась, но не представляю, как все-таки можно раскрутить цепочку зависимостей без (пере)запуска контейнера.

удалил

Это сообщение отредактировал(а) COVD - 4.10.2006, 23:34

вобсчем что-то я заинтересовался этим вопросом  пока нашел самое удачное решение от Оракл... надеюсь будет время по исследовать эту тему и по щупать в деле...

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


Однозначно. Согласен на все 100%. Хотели на хибернейт перевести. Но сейчас порсто немного подождём и пересядем на EJB3.0.



У нас очень мало(ничтожно мало) методов, которые поддаются джиюнит-тестированию без хвостов.
Те, которые есть, просто запускаются - и всё. зАчем контейнер стопорить-то???
Основная функциональность - завязана на сложныую бизнес-логику и базу.
То есть основные тесты - это те же юниты, которые прогоняют целые процессы. Для них уже нужен рестарт с переподготовкой датасета базы.
Всё отлично.

Упрощённо, полный цикл сборки:
Сборка, поготовка датасета(скл-скрипты и джава-лоадеры), деплой, 
тесты(все), андеплой, стоп сервера, опять чистый датасет, старт сервера, деплой - Всё чистенькое и готово!
То есть - подготовка, тесты, ре-подготовка

Всё под антом и круизконтролем. Очень удобно. (Если бы ещё грёбаный ЦВС не заглюкавил пару раз   )


ЗЫ: можно чуть подробнее о "хвостах", которые так сильно мешают жить? 

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

Я бы попросил!!!       

Браузер и апач - это уже распределённая система - (Функцииональность распределена, работают в связке, на различных хостах, логически - единое целое.)
Другое дело - как распределена система.

Можно, конечно, обойтись вэб-сервисами...

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

Посмотри, кто принимал участие в создании EJB3. Если я правильно помню - всем известный Hibernate. Кроме того, в JBoss  EJB3 Persistence на этом самом хибернате и сделано.
А вот в EJB2 использовать Entity Bean... Хотя сам не использовал :-)


Мы для тестирования подняли тестовый сервер :-)
Можно придумать вариант, когда вся логика лежит не напрямую в классах бинов, а в отдельных классах. А бин только обеспечивает ресурсы (доступ к БД, конфигурирование бизнес-классов и т.д.). В этом случае для "первичного" тестирования бизнес логики можно создать свою обертку, выполняющую ту же роль, что и бины (доступ к ресурсам, ...). Для обкатки логики вполне подойдет.
В любом случае, для испытаний большого проекта необходимо создавать специальный комплекс программно-аппаратных средств. Наивно было бы считать, что что-то "большое и тяжелое" можно качественно проверить одним только JUnit'ом.


Не понял мысль, можешь пояснить?


Чего стоим, кого ждем? (с) не мой :-)