zmd00

не от одного человека слышал, что от энтити бинов стоит отказываться. объсните (если это, конечно, так) почему? что использовать в качестве альтернативы (хибернейт, ибатис или что-то еще)?

@mr_dronski

конечно PreparedStatement. а иногда и не шлет, если данные из кеша поднимает. иногда не шлет, если не имеет смысла - реализует transaction-write-behind + ordering. например, если вы в одной транзакции производите 2 апдейта записи, при этом 2-й перетирает 1-й, то будет в базу отослан только последний. ну и такого рода еще много чего.

0

@simplepilot

Я сейчас сам работаю с Hibernate. Без Spring и без EJB контейнера. Меня раздражает больше всего что мой бизнес код вручную управляет транзакциями. Причём так как у меня есть несколько классов по доступу к базе вроде как
MemberAccess - доступ только к таблицам связаным с Member
EmployerAccess и так далее
то мне приходится ухишрятся что бы все они работали с одной сесией, а для этого я сесию должен сначала создать в бизнес коде, открыть в ней транзакцию и потом передать всем этим классам что бы они могли используя эту сесию читать и писать. Когда все они отстрелялись я могу закомитить транзакцию. Или откатить её если что то не так. Всё это меня угнетает. Будь у меня EJB контейнер транзакция бы открывалась бы сама, доступ к CMP бинам и JDBC access через DataSource автоматически приклеиваются к этой транзакции. И всё само открывается, закрывается. Не надо ни какую сесию из метода в метод гонять в различные классы. Если нужна независимая транзакция, пометил метод в дескрипторе REQURED_NEW и всё, он у тебя независимый. А с Hibernate этого ничего нет, всё сам, всё сам. И не верю я что Spring это делает, думаю будет какое то дурылово, по концовке открывать сесию, открывать и закрывать транзакцию всё равно будешь сам. Или придётся так код переделывать что потом без Spring он не будет работать вообще и если вдруг надо будет от Spring отказаться надо будет потратить миллион дней. Так что моё мнение лучше EJB ничего не было и нет. :-)

0

@mansch

а у нас прямые jdbc call

0

@Danissimo

2simplepilot:
Можно ведь из Session Beans все делать... Не пробовал? Transaction Management там тоже работает

0

@mr_dronski

2 simplepilot.

сочувствую. я бы сам никогда не стал Hibernate пользовать, если все делать руками. но... (вся наша жизнь из но...). в том то и дело, что Spring делает то, что раньше мог делать только большой тяжелый контейнер. и это не дурылово растекаться маслом по форуму не буду, но скажу, что сейчас в Spring я (пока что) не делал только кластер. Просто потому, что в последнее время не нужно было. Хотя есть у меня мысли по этому поводу, которые стоит проверить Сложного особо ничего.

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

если все же решитесь глянуть на Spring, то скажу, что это может оказаться для вас откровением года обратно сползать не очень захочется (да и не нужно, технически все уживается хорошо). на первоначальное освоение уйдет неделя при большом желании.

0

@simplepilot

2 Danisimmo
Нет EJB контейнера, нету. Просто нет.

2 mr_dronski
Я бы перешёл на Spring мне недели не жалко. Я про них ещё год назад когда они только появилсиь читал. Но у меня на проекте трое ТАКИХ(!) чуваков. Что они hibernate боятся а уж Spring их окончательно добёт

0

@onsh76

to mr_dronski:
>> обратно сползать не очень захочется (да и не нужно, технически все уживается хорошо).

Andrew, зoлoтые слoвa! Нa все 100% сoглaсен с тoбoй!

to vasyav:
>> У буржуев это путь к светлому завтра: Лутше нанаять 3 человека >>которые разбираються в маленьких частях чем 1-го который знает все >>и при этом 3-м платить меньше.
Былo бы интереснo узнaть прo светлoе зaвтрa у 'небуржуев', рaди интересa. Пo мoему принцип в бизнесе oдин: get max profit with less expenses, и oн пo мoему country-independent, не тaк ли?

0

@(Phantom)

>EJB - не технология для начинающих. сколько я проводил итервью, а >найти толкового человека по EJB очень трудно. считать, что лучше >меньше, да лучше - себе дороже. эти трое дешевых начинающих таких >дров наломают, что проект завалить могут. ведь не зная сильных и >слабых сторон Entity Beans, невозможно правильно обойти все проблемы. >да хотя бы возьмите пример проблемы n+1 selects. я тут недавно на >проекте разгребал подобное. мало того, что поиск шел по like '%ABC%' >(когда вырубаются все нормальные индексы в базе), так потом еще эту >туеву хучу читали в память по одному. получалось иногда до 20 000 >запросов на один use case. база на коленки встает, application server >с грохотом падает.

Может я неправильно выразился, чуть. Про 3-х чел, я говорил, что они специалисты, но они разбираються только в свом деле. Если прочитать спецификацию EJB, то уже сущ. разделение: разработчик, асемблер, человек занимающийся внедрением, администратор, поставщик готовых бизнес решений. Вот я о чем, я смотрю, что на форуме большинство, которое разбираеться сразу во всем, но помойму в мире обратная ситуация. Такое только на просторах постСССР, но один недостаток это подхода, что один человек разбираеться во всем: человек болеет, ему нужен отпуск и он не может работать 24х7.

Та что, я думаю что это ответ и на:
>Былo бы интереснo узнaть прo светлoе зaвтрa у 'небуржуев', рaди >интересa. Пo мoему принцип в бизнесе oдин: get max profit with less >expenses, и oн пo мoему country-independent, не тaк ли?
Обидно, но его похоже небудет, тот кто платить тот и музыку заказывает.

0

@mr_dronski

в EJB спецификации 6 ролей, но это все теория. в моей сегодняшней компании пробовали ввести разделение подобное (слава богу, еще до того, как я пришел . четко разграничили ответственность presentation (Struts + JSP), business (Session beans + Entity beans calls), и человек, который все это хозяйство мапил (в случае EB) и деплоил, настраивал, объявлял ресурсы и рисовал дескрипторы. И серьезно были настроены.

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

а Spring все-таки очень советую. кода станет меньше. воспользуйтесь еще метатэгами (a la XDoclet), и вы получите объявление транзакций и секьюрити ролей без геморроя дескрипторов. (я, кстати, уже постил в этот форум не так давно пример метода Hibernate, когда есть Spring: http://relib.com/forums/topic.asp?id=824365). можно и еще проще часто.

0

@simplepilot

Принцип наёма сотрудника на работу.
У вас есть два человека 1 - стоит 90К в год и он знает весть цикл работы J2EE (EJB, JSP/Servlets/Struts,MVC, сопутствующие технологии, умеет деплоить софт на xNix). Втрой знает как написать EJB но в остальном не разбирается (я правда скорее скажу что более вероятен вариант знает JSP и больше не в чём не разбирается но не важно). Так вот втрой стоит 60К в год. Если вы решите Ок - втрой дешевле беру его. Вы сэкономите 30К но ! работу всё равно делать надо, кто то должен деплоить на Юникс, интегрировать весь J2EE stuff. Но у вас есть только 30К за эти деньги просто уже никого не реально нанять. Так что придётся вам брать человека за 90. Или вам нужно 120К что бы нанять двух. Но зная текущее положение на рынке. Learning curve идёт таким образом что человек учится с простого в сторону сложного. Людей которые знают сложные вещи (Как EJB) и не знают web tier (JSP etc) - то есть согласны работать за маленькие деньги очень мало (я не видел не одного). Так что работадатель ищет всё в одном. Кто не верит советую посмотреть заметки на www.monster.com

0

@mselez

Интересно, а клиент-сервер приложения без этих технологий (EJB,..) еще кто-нибудь делает? Вот например база данных SQL Server. Там есть встроенные процедуры (наверное, не менее эффективно, чем PreparedStatement), есть внутренний кеш (отдайте 2Гб памяти базе, а не яве), есть обработка транзакций, т.е. получается, что база данных тоже может основные функции аппликейшн-сервера выполнять (кеш, транзакции). Как вы думаете?

0

freem

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

@mr_dronski

middleware для того и развили до сегодняшнего уровня, чтобы не было все в базе.

кластер application servers легче создать, чем кластер баз данных. а база может оставаться на одном сервере.

и хранимые процедуры не нужно игнорировать. иногда - это единственный способ, который удовлетворяет требованиям производительности. но если все в процедуры засунуть, то scalability будет ниже, чем в application server.

0

@Danissimo

Такое проект будет иметь много проблем (если это не форум или вебический магазин на три страницы)
1) Страдает понимание
2) Не ОО
3) В следствие предыдущих причин растет стоимость
4) Растет время разработки
5) Проблемы с разными фичами, не свойственными СУБД: асинхронные сообщения, собственные кеши, асинхронный процессинг. Я знаю, где-то как-то это делается, но, во-первых, это vendor specific, во-вторых, скорее всего нереализуемо в том объеме, в каком можно реализовать на middleware.
6) Рост сложности клиентов.
Короче, все-то, что решается на уровне EJB.

0

@mselez

Вот и было бы интересно посмотреть такую статистику, скажем, EJB не применяют в:
1. форумах
2. интернет-магазинах где каталог < N наименований
3. ...
Понятно, что технология относительно новая (но уже устаревает, теперь Hibernate более круто) и вряд ли возможно так кокретизировать.

Я не имел в виду вообще отказ от среднего слоя. Но он не обязательно должен быть на готовых конструкциях типа EJB. Что такое кеш? Берем Hachetable и кладем туда обьекты. Иногда это проще, понятнее и быстрее, чем универсальные решения на все случаи жизни. Но тут я не оргинален .

0

@Danissimo

Ну, давайте посмотрим, что предлагают J2EE серверы
1) Transaction Management
2) Clustering
3) Authorization based on roles
4) Failover control
5) Hot deployment
6) Messaging
7) Remote calls
может быть что-то еще.

Вычеркните из этого списка то, что вам не нужно. Если остался только Transaction Management, например, то со 100% уверенностью можно сказать, что без EJB можно спокойно обойтись. Зачем брать технологию и использовать ее на 10-20%.

С другой стороны, какие есть альтернативы? Например, можно поискать какие-нть frameworks, выполняющие нужную работу. У них свои баги (у J2EE серверов тоже есть баги, и не мало . Ими пользоваться нужно учиться. Можно написать свой фреймворк, заточенный специально под задачу. Правда, такие frameworks пишутся уже 'потом'

Короче, нужно отдавать себе отчет, чего хотим от EJB. Можно и Entity Beans использовать. Можно альтернативы. Тут и там свои плюсы, свои минусы. EJB люди научились использовать. Легче найти человека. Зато уважаемые J2EE серверы дорогие. Масса но...

Короче, нет однозначного ответа. А чего вы хотели, собсно?

0

@mselez

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

0