ORM?

[metaclass]

Цитата из статьи с сайта 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 страниц вчера, сегодня налабал прототип софтины, а через год мне не нужно будет стоять в раскоряку на гамаке в скафандре, чтобы дорабатывать софтину в соответствии с изменившимися требованиями".

Comments

[metaclass.livejournal.com]

Им червь воспрещает сделать по-человечески)

[feorex.livejournal.com]

А какую ORM использует ребе в своих проектах?

[fraks-nsk.livejournal.com]

А зачем их вообще использовать? Они ведь только мешают общению с базой на нормальном sql-языке, являются лишней прокладкой со своими червями.

[metaclass.livejournal.com]

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

[avnik.livejournal.com]

Хороший орм никогда не мешает написать запрос ручками.
Польза от них -- избавление от заката солнца вручную, в тех местах которые пишутся 95% времени разработки, и при жизни проекта выполняются редко и на малом объеме данных. (и от считания на пальцах -- в каком по счету элементе кортежа будет foo.bar из select ...., foo from bar, ... когда там полей так 40 из разных таблиц)

[norguhtar.livejournal.com]

Чтобы не закатывать вручную солнце в CRUD.

[metaclass.livejournal.com]

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

[hamster37.livejournal.com]

Мне интересно как это у вас реализовано: что есть в моделях, и как реализована связка генерящегося кода и того, который пишется руками? Я с ходу вижу два варианта: 1) генерятся отдельные модули, которые руками не правятся, и эти модули предоставляют какой-то апи для остальных; 2) есть свой препроцессор и генерящийся код вставляется в рукописный прямо перед компилляцией. Или что-то другое?

[denisioru.livejournal.com]

универсальные ORM обязаны эти костыли иметь. Либо иметь херову тучу драйверов для поддержки движков. Ибо SQL хоть и стандарт, но разброд и шатание в синтаксисе и фичах настолько обширный, что слово "стандарт" тут уже как насмешка звучит.

[fraks-nsk.livejournal.com]

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

[denisioru.livejournal.com]

Ну, возможно, потому что имея представление и умея работать с nHibernate программер может один проект сделать для MSSQL, другой для Oracle, третий для DB2 например. А будь разные ORMы - в каждом пришлось бы проходить по своим граблям. Хотя от них и так не избавиться, но поменьше будет.

[stdray.livejournal.com]

>если в основе технологии лежит грамотная и проработанная теоретическая модель - ей легко пользоваться, она помещается в мозг и технология будет реализована более-менее однообразно.

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

[metaclass.livejournal.com]

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

[stdray.livejournal.com]

Известное http://citforum.ru/database/articles/vietnam/
И в отличии от реляционной теории у ООП нет теоретической базы. Потому возникают ПРОБЛЕМЫ.

[fraks-nsk.livejournal.com]

Вы можете привести пример когда ORM дает какие-то реальные плюсы?

[stdray.livejournal.com]

Типизация какая-никакая. Есть одна поделка с хардкорными сиквеловскими запросами прямо в коде и строковой типизацией. От туда постоянно какая-то фигня всплывает. В некоторых ORM генерация мапингов более-менее автоматизирована, потому чуть меньше работы делать приходится.

[osdm.livejournal.com]

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

Без ORM как минимум на каждую таблицу пишешь по классу, потом по одному запросу select/insert/update/delete, и на каждое поле прописываешь биндинг между классом и запросами (в две стороны). Итог: при добавлении нового поля 10-15 разных мест, где его нужно прописать. Как писать, так и исправлять подобную хрень долго и нудно.

С ORM классы, запросы и биндинги с БД генерируются автоматически. Итог: при добавлении нового поля исправлять приходится всего в 3-5 местах. Экономия в три раза.

[stdray.livejournal.com]

>через год мне не нужно будет стоять в раскоряку на гамаке в скафандре, чтобы дорабатывать софтину в соответствии с изменившимися требованиями

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

[gineer.livejournal.com]

\\А правильный аргумент должен быть

http://2k.livejournal.com/520078.html

эх, не зря я хранил эт ссылку ;)

[nicka-startcev.livejournal.com]

wtf ORM? Оперативно-Розыскные Мероприятия?

[berezovsky.livejournal.com]

это ТРЕНД

сука, капчю пятый раз ввожу
совсем охуели

[tzirechnoy.livejournal.com]

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

[juan-gandhi.livejournal.com]

ППКС! (тем более я для хайбернейта распределённые ключи программировал как-то однажды)

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

Короче, I see dumb people. You see dumb people. We all see dumb people.

[metaclass.livejournal.com]

Вот у меня как раз распределенные ключи :)