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 страниц вчера, сегодня налабал прототип софтины, а через год мне не нужно будет стоять в раскоряку на гамаке в скафандре, чтобы дорабатывать софтину в соответствии с изменившимися требованиями".
"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 страниц вчера, сегодня налабал прототип софтины, а через год мне не нужно будет стоять в раскоряку на гамаке в скафандре, чтобы дорабатывать софтину в соответствии с изменившимися требованиями".
no subject
no subject
no subject
no subject
Я пока ни одного нормального не видел.
(no subject)
(Anonymous) - 2012-01-20 10:13 (UTC) - Expand(no subject)
(no subject)
(no subject)
(no subject)
no subject
Польза от них -- избавление от заката солнца вручную, в тех местах которые пишутся 95% времени разработки, и при жизни проекта выполняются редко и на малом объеме данных. (и от считания на пальцах -- в каком по счету элементе кортежа будет foo.bar из select ...., foo from bar, ... когда там полей так 40 из разных таблиц)
(no subject)
(no subject)
(no subject)
no subject
no subject
Вот подумывал упростить себе жизнь и генерить NHibernate маппинги - но уже глянул, что кое-какие нужные мне фичи там реализованы кривовато.
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
no subject
no subject
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Какая модель лежит в основе ORM? Это костыль для дружбы между реляционным миром СУБД и объектно-ориентированным мирком популярных ЯП. Какая теоретическая модель лежит в основе? Имхо, проще принять как факт, что ORM проектируется исходя из приоритетов юзкесов в голове разработчика. Следовательно, есть шанс, что важные для вас возможности будут неважны для разработчика, а также шанс, что у разработчика изменятся взгляды и в один прекрасный день он переделает "как надо".
no subject
no subject
И в отличии от реляционной теории у ООП нет теоретической базы. Потому возникают ПРОБЛЕМЫ.
no subject
no subject
(no subject)
no subject
Без ORM как минимум на каждую таблицу пишешь по классу, потом по одному запросу select/insert/update/delete, и на каждое поле прописываешь биндинг между классом и запросами (в две стороны). Итог: при добавлении нового поля 10-15 разных мест, где его нужно прописать. Как писать, так и исправлять подобную хрень долго и нудно.
С ORM классы, запросы и биндинги с БД генерируются автоматически. Итог: при добавлении нового поля исправлять приходится всего в 3-5 местах. Экономия в три раза.
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
(no subject)
no subject
Смотря что писать же. Бывает, что предметная область меняется чаще чем раз в год. Раз в годик-то постоять в раскоряку надо. Иначе, что за работа такая получается)
no subject
http://2k.livejournal.com/520078.html
эх, не зря я хранил эт ссылку ;)
no subject
no subject
сука, капчю пятый раз ввожу
совсем охуели
(no subject)
no subject
no subject
Проблема-то в том, что все громко орут, толпа невежд, и для них разницы нету, моноид, группоид, аппликативный функтор, xml, json, системный вызов, битовый флаг, порядок байтов, устройство мьютексов и приоритетных очередей...
Короче, I see dumb people. You see dumb people. We all see dumb people.
no subject