expp- хибер позволит тебе правильно закодить бизнесс-логику приложения используя весь оо/паттерн-стафф, тем самым избежать как споков так и огромных копипастеных методов "public static int do(...)" (бизнесс логика это типа сложные и согласованные изменения в домене)
Неужели? Т.е. ставится тезиз, что хибернейт - это правильный способ организации бизнеслогики? Кто это сказал, и кто именно доказал, и почему тогда Oracle, SAP не переводят массовым порядком свои новые и старые разработки на хибернейт (или EJB3)? Что им мешает то, неправильным?

Впрочем, это все теория (правильности), а на практике - ты можешь привести примеры и замеры миграции: вот была "старая" система, не нормальная (и в чем она была ненормальной), вот вы её перевели (она стала нормальной, и в чем)?

Сколько человеко-часов было сэкономлено, каких высот производительности удалось достичь?

expp- хибер ооочень легко позволяет организовать кэширование и кластеризацию.
Насколько легче, чем в какой либо другой технологии? Преимущества в чем?
~
даю вопрос на затравку: насколько легко реализуется межнодовый синглтон (конкурирующий доступ, к примеру, за банковский счёт). В транзакционной модели (оптимистичных блокировок), естественно?

exppнормальные люди эта в книшка читать
А кто спорит? Только в книжках про реальные проекты - ничего не пишут. Вот что странно.

------

Обвинить другого в том, что он "засрал" топик непонятным для тебя - это просто. Но так ли просто высказать осмысленное то из собственного опыта?

Cknown grexhideНеужели? Т.е. ставится тезиз, что хибернейт - это правильный способ организации бизнеслогики? Кто это сказал, и кто именно доказал, Доказали 30 лет практики очевидно, разгребаний хранимок, написанных немытыми иммигрировавшими украинцами в сравнении с более дешевой и правильной разработкой на принципах OOA&D
Где именно есть примеры замеров и убедительных доказательств (вместо аксиом), что разработка на OOA&D является более правильной и более дешевой (или в общем случае, или в конкретном)?

Производились ли такие сравнения вообще?

Cknown
и почему тогда Oracle, SAP не переводят массовым порядком свои новые и старые разработки на хибернейт (или EJB3)? Что им мешает то, неправильным?Затем, что не каждой задаче поможет Domain Model. Тебе например с АРМ-Склад, или единой государственной автоматическойсистемеучета пойла Domain Model не поможет. Так зачем разработчик реляционных хранилищ будет тратиться на разработку того, что не всем его клиентам нужно?

Ок, в каких именно задачах (и чем) помогает Domain Model?
Можно озвучить примеры классов задач, примеры успешных реализаций?

Можно увидеть примеры действительно успешных, тиражируемых систем, построенных на EJB3 или Hibernate? В чем именно преимущества этих систем на этапе сопровождения и развития (не говоря уже про эксплуатацию)? В сравнении, естественно?

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

Или вообще что? В чем преимущества то? В сравнении, в замерах?

Где примеры и доказательства (очевидных вещей?)

Blazkowicz grexhideЕще раз. Я могу прочитать гугл, это не проблема.
Для особо доходчивых повторяюсь: меня интересует именно твоё, личное мнение, а не цитирование чужих мыслей. Если своих мыслей у тебя нет - до свидания, лишний флуд - не интересен.
Другими словами, что такое ORM и для чего он нужен ты не знаешь и не понимаешь. У меня нет желания выкладывать здесь прописные истины ради флудера который второй топик засирает.

А ты сейчас что сделал? Вместо того, что бы объяснить "прописные" "истины" - тупо засрал своим "мнением об котом то там"?

Blazkowicz
grexhideИтак, повторяюсь еще раз: кто, и покаким причинам считает Hibernate прогрессивной технологией, однозначно (и в чем) позволяющий достичь ему качественно нового уровня при разработке?
Hibernate круто потому что это лучший ORM
Вещь в себе. Лучший ORM? Ок, допустим.

BlazkowiczHibernate круто потому что в отличие от других ORM он поддерживает множество фич для совместимости с Legacy структурами БД
В отличии от других ORM? Опять вещь в себе

BlazkowiczORM круто потому что с ним не надо заботится про примитивные CRUD вообще. От того, что CRUD стал делаться еще одним способом - от этого что то изменилось?
В чем отличия? Тебе нужно писать меньше кода? Чем в других ORM? Опять вещь в себе (и ниачем - см. TopLink или BC4J).

BlazkowiczORM круто потому что с ним количество работы над запросами к БД можно свести к минимуму, таким образом разработка проходит как бы в 2 этапа.
Т.е. если тебе нужно получить данные из таблицы, то это происходит автоматически, по "щучьему велению и моему хотению"? Т.е. система сама для тебя пишет все необходимое для доступа к данным (структуры классов, фильтры, группировки, суммирования)? Ты вообще о чем?

BlazkowiczНа первом все работает на простейших CRUD и делается в считаные часы.
На непростейших это делается (и делалось) за минуты? И?

BlazkowiczЗатем в эту наработку вводятся сложные запросы для улучшения перфоманса или реализации не тривиальной функциональность.
Это ты о чем вообще? Поясни, ниасилил.

BlazkowiczОпять же сколько мы ни вводим новых запросов, нам все равно не надо заботится о том что оно как-то не так ляжет на объекты. Потому что об это позаботится ORM.
А зачем тебе что то ложить на объекты? Пример реальной задачи?

BlazkowiczORM дает широкий спектр возможностей по ленивой загрузке данных.
Ты про lazy fetch? А где его нет (ну да, нет в ADO.NET, ну и что?)

BlazkowiczТо есть мне не надо писать запросы, ORM их сам реализует достаточно оптимально, но при этом я легко контролирую когда и какие данные мне надо получить.
Насколько оптимально? В чем измеряется оптимальность? Примеры аналитических функций Oracle уже тоже реализваны? Почему же тогда Hibernate не применяется вовсю в OLAP и DWH (вот дебилы, не знают наверно про мегафичерсы, да?)

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

BlazkowiczБез ORM нужно было бы для каждого случая писать или генерить запросы, а потом ещё и заботится о том чтобы они легли на объекты приемлемые для обработки бизнес логики.
Я не знаю ни одной системы, в которой нужно заботиться об "ложении". Все происходит автоматически (ну кроме EJB2, но это не интересно).

Итак - каким образом Hibernate сам за меня построит комплексный запрос с RANK, KEEP, OVER BY конструкциями (подсказка - промежуточные итоги, накопительные суммы и прочее)?

BlazkowiczВыше поднимался вопрос про Кэширование?
А в какой технологии его нет? CachedUpdates в той же Delphi - чем тебе не кэширование (это как базовый примитив)?

BlazkowiczИменно с Hibernate я могу прикрутить кэширование к проекту в течении часа.
Два клика мышью.

BlazkowiczИ потом остается только тюнить его настройки, в зависимости от наблюдаемомго перфоманса и требований.
И? Тоже самое, 1:1

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

BlazkowiczДальше список просто лениво продолжать, все равно никто не оценит.
Даже сами яверы?

BlazkowiczНичего подобного чтобы позволяло бы объединить все достоиства как ООП так и RDB и предложить такую скорость разработки я ещё не видел.
А ты хоть пытался смотреть?

BlazkowiczНу, и чтобы тут вдруг не возникли дурацкие попытки обвиниьт кого-от в поклонении хиберу - заявляю отдельно. Хибер и ORM не панацея, это раз.
А что два? Это и не технология, достойная применения - почитай Кайта, он вполне доходчиво высменивает попытки некоторых не шипко умных товарищей делать то, что куда лучше делает сама RDBMS. Только вот незадача - никто читать (30-ть томов по 1000 листов) не хочет (в равной степени как и по ABAP) - куда проще охаять старое, сделать "новое" (ничем не лучше, разве хуже) и тем
быть "счастливым" (типа вы тут все до меня были идиоты, ща я покажу как надо).

А что надо то? На самом деле?

BlazkowiczORM как подход имеет в себе ряд проблем которые раскрыты здесь
Хоть что то интересное.... впрочем, это, кстати, цветочки ;)

expp grexhideНеужели? Т.е. ставится тезиз, что хибернейт - это правильный способ организации бизнеслогики? Кто это сказал, и кто именно доказал, и почему тогда Oracle, SAP не переводят массовым порядком свои новые и старые разработки на хибернейт (или EJB3)? Что им мешает то, неправильным?
ты задрал со своим массовым переводом. поню конятно что деньги вкладываются в то что выгодно. своё будущее и оракл и сап очертили довольно явственно (выпуском NetWeaver c ejb3 вторая десятилетием toplinkа и покупкой berkleydb) только тебя спросить забыли.

Они и себя забыть спросили, не только тебя и меня. Когда мы увидим SAP R/4 исключительно на яве или OEBS исключительно на ней же?

Никогда?

expp
да тезис ставиться именно такой. и нехрен его подменять какойто ботвой. просто докажи что sql update это лучше.
Расскажи чем хуже, что ли?

expp grexhideВпрочем, это все теория (правильности), а на практике - ты можешь привести примеры и замеры миграции: вот была "старая" система, не нормальная (и в чем она была ненормальной), вот вы её перевели (она стала нормальной, и в чем)?
у меня нет планов рассказывать что и как на моём проекте. халилуя что мы таки дошли до orm. об остальном спроси у тех кто за это платил
Т.е. ты ничего сказать не можешь? А зачем встрял?

expp grexhideНасколько легче, чем в какой либо другой технологии? Преимущества в чем? млин. взял hibernate tutorial и задеплоил его на кластер. расставил по домену режимы кэширования. имхо достойно.
grexhide
даю вопрос на затравку: насколько легко реализуется межнодовый синглтон (конкурирующий доступ, к примеру, за банковский счёт). В транзакционной модели (оптимистичных блокировок), естественно? treecahce tutorial
И это что легче, чем SELECT FOR UPDATE? ;)))))

expp grexhideА кто спорит? Только в книжках про реальные проекты - ничего не пишут. Вот что странно. ага Фаулер, Кинг, Бауер etc просто кучка щеглов не нюхавших реальных проектов. Сидят себе пишут хню всякую. Нет чтоб пра делфи написать
Ты думаешь, что они что то реальное делают? Вместо того, чтобы с умным видом "советы" вот таким как ты раздавать? Эккий ты наивный, однако ;)

expp grexhideОбвинить другого в том, что он "засрал" топик непонятным для тебя - это просто. Но так ли просто высказать осмысленное то из собственного опыта?
это мне твоя членометрия непонятна??. ты много на себя взял. ты их просто реально засераешь сериями "1. боян 2. всёхня 3.пошлифсенах"
Я? Боже упаси, какая членометрия.

Я задал предельно простой вроде бы вопрос: "Мужики, расскажите мне, неучу, в чем сила"?

Вот брат говорит - что в деньгах. Я вот считаю - что в правде. Только где правда то? Вот товаришь выше дал пример правды - хоть что то (из отряда самокритичности и реальной рефлексии).

Остальные пока только слюной побрызгали... пользы никакой - чистой воды флуд и засирание (и потом еще меня обвиняют ;)))) В зеркало бы посмотрели, что ли...

Blazkowicz grexhideГде примеры и доказательства (очевидных вещей?)
Докажите мне что земля круглая? да?

В чем трудность? Компас в руки и вперед. Есть шанс, что ты вернёшься в обратную точку, идя в заданном направлении.

Убедительно? Весьма.

--

Попытки же ORM-щиков доказать правильность голыми тезисами аки шапкозакидательство, увы, такого доказательства не дают.

Есть примеры (подавляющее большинство) успешных систем, которые обходятся без ORM вообще (Cobol, ABAP, PL/SQL). При том количество (местами и качество) решений - на два порядка (т.е. раз в сто минимум) больше, чем на ORM.

Что они делают не так? Не тем компасом пользуются? ;))))))

fixxer grexhide
Есть примеры (подавляющее большинство) успешных систем, которые обходятся без ORM вообще (Cobol, ABAP, PL/SQL).

Да потому что ценность наработанного годами legacy кода и отработанного процесса выше. У тебя, подозреваю, такая же история.


fixxer[quot grexhide]
При том количество (местами и качество) решений - на два порядка (т.е. раз в сто минимум) больше, чем на ORM.

С какими решениями на базе ORM ты сравнивал?

Oracle CRM (iProcurrement)
Oracle Collaboration Suite
Oracle BI (Wareahouse Builder)

Oracle Enterprise Manager

NetWeawer (отдельная укатайка, на практике)

Documentum (в т.ч.)

Ну и так, по мелочи (в части поиска более адекватных аналогов озвученному выше).
Только по первому я выступал в роли девелопера, остальные - просто оценивал
применимость (предпроект).

----

Каждое в своей нише сравнивалось (с не-Java решениями). Java - как правило - стойкая ситуация от "что за бред" до "полный пи..ц". По всем параметрам - от юзабильности до производительности и надёжности. Documentum внедрили только (и то, с огромным скрипом, могли бы и попроще и подешевле, но там была политика).

На Hibernate вообще ничего не видел (даже оценивать нечего). Такое ощущение, что стек - какая то игрушка для детсада.

Потому и пытаю - что за мотивы то такие? В чем причина такого будоражения в умах в пользу этих откровенно деОRМотехнологий (которые ну никак не тянут на увеличение показателей конечных решений)?