Роман Дынник

Вот что меня удивляет в поклонниках "болтов" и прочих супер-пупер ORM, так это то, что у них слишком много "кажется".

Ну зачем же так! Вы читатели мой ответ в топике про ОРМ? Есть маппинг на ХП в Hibernate - т.е. в ОРМ для java - т.е. которая полностью кроссплатформенная

Насчет обкатывания - это не MS и "обкатываеть" Hibernate 3 стали еще с альфы - можете скачать ее и обкатывать самостоятельно... Так что есть все основания считать что резил будет очень стабильным и качественным

Templar

ORM, в первую очередь - заменитель работы с датасетами типа дельфийских или ADO.

Вы уже пару раз повторили эту фразу. На мой взгляд, вы сравниваете цель и средство – что совершенно не корректно. ORM – это механизм позволяющий делать обычные plain-объекты сохраняемыми (persistent). Dataset’ы же – это результат работы средств доступа к БД типа ADO, ODBC, JDBC и т.д. Т.е. принципиально разные вещи.
В случае если решено использовать только датасеты – вы фактически ограничиваете будущую архитектуру клиентского приложения. Т.е. ничего кроме форм для ввода вы на них не построите. Если же по тем либо иным соображениям вы хотите получить полноценный слой domain-объектов (domain layer), то вам так или иначе придется обеспечивать им возможность длительного сохранения в БД. Да вы можете сделать его руками используя прямые обращения к БД через, например, ADO или JDBC. Другой вопрос зачем – если эта задача сейчас уже решена.


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

Неужели различного рода маркетинговые заявления MS уже стали считаться весомым аргументом в споре? Ну нет у MS на данный момент ни одного сервера приложений для управляемого кода – поэтому официальная позиция что они и не особо нужны. Тем не менее MTS они в свое время все-таки сделали :)

К тому же стоимость владения – это такая вещь… Вот к примеру JBoss – какая у него стоимость владения?

Однако, использование мапперов не только у "юных дарований", но и у вполне зрелых спецов может вызывать иллюзию, что СУБД вообще не нужна.

А как ОРМ влияет на саму СУБД? Т.е. как вообще можно говорить об ОРМ без СУБД?

JDO - стандарт на средства ORM в java! Это позволяет независимым поставщикам реализовывать свои продукты согласно этому стандарту. У MS ничего подобного JCP нет (оно им и не нужно). Стандартизация же C# - это просто маркетинг - какая кому разница что он страндартизован? Или вы заметили вдруг начавшуюся тенденцию к реализвания .net framework кем-то еще кроме MS?

Ну и слова о том что Sun - собака на сене (особенно в сравнении с MS) я вообще оставлю без коментарием. Интересно, вы на java вообще работали?


Alexey Rovdo

Насчет производительности

Используя ORM вы автоматически получаете и такие вещи как lazy-loading и кэширование – это в свою очередь для многих приложений даст определенный выигрыш в производительности. Ну и у большинства данных продуктов уже в документации сказано, о том какие классы задач стоит решать, используя ORM и какие нет. К тому же, используя ORM для реализации DAO, вы сэкономите намного больше времени, чем потребуется для оптимизации действительно узких мест.


Но здесь следует отметить и такой приятный факт - упомянутые выше средства O/R-мэппинга можно прекрасно использовать и в двухзвенных приложениях.

Полностью согласен! Я думаю, общественность вводит в заблуждение многослойная архитектура. На самом деле она совсем не исключает реализацию бизнес логики на сервере БД в виде хранимых процедур.

Templar

Относительно Java - Sun, IBM, Oracle за последнее десятилетее вложили туда столько денег, что можно было ожидать на порядок лучшего результата и как минимум - появления отраслевых стандартов вроде SQL, С/С++, C

А вы точно понимаете что пишите?

Да без проблем – если сказать нечего то лучше промолчать! К тому же я не только вам пишу.