metaclass: (Default)
metaclass ([personal profile] metaclass) wrote2012-01-20 12:14 pm

ORM?

Цитата из статьи с сайта NHibernate, про то, "как использовать NHibernate с legacy базами, где в поле для внешней ссылки без значения ставят 0 вместо null":
"NHibernate is bad in many aspects, but the only thing we can’t blame is extensibility."
и далее - бездны ада и конфигурации NHibernate для этого частного случая.
Заодно глянул во внутренности NHibernate, класс Dialect, посмотреть, как же они реализовали работу с различными СУБД. около 150 методов, из них около 50 - bool флаги на тему "поддерживается ли эта фича"/"расположена фича до или после запроса", около 80 - "какая строка нужна для реализации этой фичи до запроса/после запроса" и тому подобное.
Особенно стремно выглядит работа с identity/sequence и прочими автогенерируемыми первичными ключами.
В общем, внутренности ORM кромешно адовы, а когда язык не позволяет метапрограммирование хоть как-то - там вообще холокост.

Это ж я все по поводу айсед-дотнет-срача (http://theiced.livejournal.com/143962.html) пытаюсь понять, может я все-таки не прав, и готовыми либами все-таки можно пользоваться и они не будут выворачивать мозг наизнанку от осознания того, что их авторы умеют хорошо программировать, но не понимают, что они делают с точки зрения теории.

Т.е. у меня идея такая: если в основе технологии лежит грамотная и проработанная теоретическая модель - ей легко пользоваться, она помещается в мозг и технология будет реализована более-менее однообразно.
А когда это сделано на основе ad-hoc бреда, рассчитано на фабрики из сотен индусов, вручную рисующих в вижуал-студии диаграммы и дорабатывается по принципу "что попросил vip-клиент из Бразилии" - то пользоваться этим белому человеку невозможно.
Если же базовая модель не проработана, то даже при наличии стандартов будет стопицот реализаций, одна другой страшнее и у каждой будут свои пропоненты, все аргументы которых сводятся к одному "я использую эту технологию 5 лет и у меня нет никаких проблем с ней никогда".
А правильный аргумент должен быть "я про эту технологию слышал раньше, прочитал 100 страниц вчера, сегодня налабал прототип софтины, а через год мне не нужно будет стоять в раскоряку на гамаке в скафандре, чтобы дорабатывать софтину в соответствии с изменившимися требованиями".

[identity profile] metaclass.livejournal.com 2012-01-20 09:24 am (UTC)(link)
Им червь воспрещает сделать по-человечески)

[identity profile] feorex.livejournal.com 2012-01-20 09:33 am (UTC)(link)
А какую ORM использует ребе в своих проектах?

[identity profile] fraks-nsk.livejournal.com 2012-01-20 09:36 am (UTC)(link)
А зачем их вообще использовать? Они ведь только мешают общению с базой на нормальном sql-языке, являются лишней прокладкой со своими червями.

[identity profile] denisioru.livejournal.com 2012-01-20 09:39 am (UTC)(link)
универсальные ORM обязаны эти костыли иметь. Либо иметь херову тучу драйверов для поддержки движков. Ибо SQL хоть и стандарт, но разброд и шатание в синтаксисе и фичах настолько обширный, что слово "стандарт" тут уже как насмешка звучит.

[identity profile] fraks-nsk.livejournal.com 2012-01-20 09:41 am (UTC)(link)
А зачем вообще с сервера на сервер прыгать? таким образом не получится использовать самое вкусное что в серверах есть, а если все на уровне элементарных select - то тем более - зачем выбранный сервер менять на другой?

[identity profile] denisioru.livejournal.com 2012-01-20 09:44 am (UTC)(link)
Ну, возможно, потому что имея представление и умея работать с nHibernate программер может один проект сделать для MSSQL, другой для Oracle, третий для DB2 например. А будь разные ORMы - в каждом пришлось бы проходить по своим граблям. Хотя от них и так не избавиться, но поменьше будет.

[identity profile] stdray.livejournal.com 2012-01-20 09:46 am (UTC)(link)
>если в основе технологии лежит грамотная и проработанная теоретическая модель - ей легко пользоваться, она помещается в мозг и технология будет реализована более-менее однообразно.

Какая модель лежит в основе ORM? Это костыль для дружбы между реляционным миром СУБД и объектно-ориентированным мирком популярных ЯП. Какая теоретическая модель лежит в основе? Имхо, проще принять как факт, что ORM проектируется исходя из приоритетов юзкесов в голове разработчика. Следовательно, есть шанс, что важные для вас возможности будут неважны для разработчика, а также шанс, что у разработчика изменятся взгляды и в один прекрасный день он переделает "как надо".
Edited 2012-01-20 09:46 (UTC)

[identity profile] fraks-nsk.livejournal.com 2012-01-20 09:46 am (UTC)(link)
Т.е. он будет использовать только то подмножество SQL что общее у всех.
За для чего ему тогда сервер менять?

[identity profile] metaclass.livejournal.com 2012-01-20 09:48 am (UTC)(link)
Я MDA использую - у меня все генерируется из моделей. В том числе и код, который гоняет данные между объектам и базой данных.
Вот подумывал упростить себе жизнь и генерить NHibernate маппинги - но уже глянул, что кое-какие нужные мне фичи там реализованы кривовато.

[identity profile] fraks-nsk.livejournal.com 2012-01-20 09:49 am (UTC)(link)
К примеру у Firebird и MS SQL совершенно разный подход к работе с транзакциями и работать одинаково с обоими серверами можно только с очень простыми конструкциями которые обкорнают нафиг особенности реалиации обоих серверов.

Получается внедрим прокладку ORM и будем затачивать работу с серверами под нее.
Edited 2012-01-20 09:50 (UTC)

[identity profile] metaclass.livejournal.com 2012-01-20 09:49 am (UTC)(link)
Ну вот определенная категория лиц убеждает, что они заебись.
Я пока ни одного нормального не видел.

[identity profile] stdray.livejournal.com 2012-01-20 09:50 am (UTC)(link)
>через год мне не нужно будет стоять в раскоряку на гамаке в скафандре, чтобы дорабатывать софтину в соответствии с изменившимися требованиями

Смотря что писать же. Бывает, что предметная область меняется чаще чем раз в год. Раз в годик-то постоять в раскоряку надо. Иначе, что за работа такая получается)

[identity profile] denisioru.livejournal.com 2012-01-20 09:50 am (UTC)(link)
Не факт что подмножество.

[identity profile] metaclass.livejournal.com 2012-01-20 09:51 am (UTC)(link)
Вот именно, костыль, который почти никто даже не пытался теоретически прорабатывать, поэтому творится такой ад.

[identity profile] fraks-nsk.livejournal.com 2012-01-20 09:54 am (UTC)(link)
А если не общее подмножество - то получается неперносимо.
Ну и зачем писать с прокладкой если все равно непереносимо а никаких других удобств она сама по себе не дает, окромя дополнительных головняков.

[identity profile] vp.livejournal.com 2012-01-20 09:54 am (UTC)(link)
Ну есть такая модель продаж, приходят к клиенту. У вас есть оракл? Отлично, "ставим под оракл". Нет оракла? Поставим базу "на текстовых файлах" :)

[identity profile] vp.livejournal.com 2012-01-20 09:55 am (UTC)(link)
Я вам открою тайну, что 99% народа работают с ОЧЕНЬ простыми конструкциями. Мы недавно столкнулись с одним таким :)

[identity profile] fraks-nsk.livejournal.com 2012-01-20 09:55 am (UTC)(link)
Вы можете привести пример когда ORM дает какие-то реальные плюсы?

[identity profile] stdray.livejournal.com 2012-01-20 09:57 am (UTC)(link)
Известное http://citforum.ru/database/articles/vietnam/
И в отличии от реляционной теории у ООП нет теоретической базы. Потому возникают ПРОБЛЕМЫ.

[identity profile] fraks-nsk.livejournal.com 2012-01-20 09:58 am (UTC)(link)
Если софт требует оракла - то и надо затачивать на оракла.
Если софт нормально работает с текстовыми файлами - нафига ему оракл?
И это ж на каком примитивном уровне надо юзать сервер БД что бы оно нормально перенеслось?

[identity profile] vp.livejournal.com 2012-01-20 10:00 am (UTC)(link)
Именно!!! Когда у вас таблички в 2 столбца типа "пользовтаель - пароль", или "артикль - название", как массово у народа в вебах, у них понятия о базах данных вполне сводятся к едреному универсализму. И все эти вещи, которые вы тут пишете, становятся для них похожими на пеправду :)

Мы сами на фаерберд в 5-ти проектах залочились по самое немогу.

[identity profile] fraks-nsk.livejournal.com 2012-01-20 10:00 am (UTC)(link)
Так если простые конструкции в sql - то это же какой код надо навертеть в коде что бы это заменить?
sql он на то и нужен что бы очень эффективно выражать мысли. Я вообще стараюсь писАть всю работу с данными на sql, что бы на клиенте было как можно меньше работы - ибо тупо компактнее получается, и читабельнее. И обычно намного быстрее как в написании так и в работе.

[identity profile] stdray.livejournal.com 2012-01-20 10:02 am (UTC)(link)
Типизация какая-никакая. Есть одна поделка с хардкорными сиквеловскими запросами прямо в коде и строковой типизацией. От туда постоянно какая-то фигня всплывает. В некоторых ORM генерация мапингов более-менее автоматизирована, потому чуть меньше работы делать приходится.

[identity profile] fraks-nsk.livejournal.com 2012-01-20 10:04 am (UTC)(link)
Кстати, по теме топика. Все это DB_Aware в дельфях мне кажется тоже подвидом ORM-а - я сделал себе буфер, по типу ClientDataSet но только не DV-Aware - и привязку оного к гриду. И мне больше ничего не надо. Запрос к базе выдает прямоугольную табличку - я ее складываю в буфер и юзаю. В табличку стараюсь запрашивать уже не требующее обработки, или обработка минимальна.

[identity profile] avnik.livejournal.com 2012-01-20 10:07 am (UTC)(link)
Хороший орм никогда не мешает написать запрос ручками.
Польза от них -- избавление от заката солнца вручную, в тех местах которые пишутся 95% времени разработки, и при жизни проекта выполняются редко и на малом объеме данных. (и от считания на пальцах -- в каком по счету элементе кортежа будет foo.bar из select ...., foo from bar, ... когда там полей так 40 из разных таблиц)

Page 1 of 3