![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
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
Какая модель лежит в основе ORM? Это костыль для дружбы между реляционным миром СУБД и объектно-ориентированным мирком популярных ЯП. Какая теоретическая модель лежит в основе? Имхо, проще принять как факт, что ORM проектируется исходя из приоритетов юзкесов в голове разработчика. Следовательно, есть шанс, что важные для вас возможности будут неважны для разработчика, а также шанс, что у разработчика изменятся взгляды и в один прекрасный день он переделает "как надо".
no subject
no subject
И в отличии от реляционной теории у ООП нет теоретической базы. Потому возникают ПРОБЛЕМЫ.
no subject
no subject
no subject
В свое время в дельфях заюзал персистент-поля DB-Aware и по недомыслию сделал в БД поле smallint которое потом оказалось мало. В базе поменял smallint на integer а клиент с этим делом работать отказался. Такая типизация нам не нужна.
Тем более что привязка реального поля в БД все равно только в рантайме может быть.
no subject
Без ORM как минимум на каждую таблицу пишешь по классу, потом по одному запросу select/insert/update/delete, и на каждое поле прописываешь биндинг между классом и запросами (в две стороны). Итог: при добавлении нового поля 10-15 разных мест, где его нужно прописать. Как писать, так и исправлять подобную хрень долго и нудно.
С ORM классы, запросы и биндинги с БД генерируются автоматически. Итог: при добавлении нового поля исправлять приходится всего в 3-5 местах. Экономия в три раза.
no subject
no subject
no subject
no subject
Какой трэшак.
Hint: в тупых формочках вообще не нужны классы -- ну, только в качестве внутренней реализацыи контролов этих формочек. Тупые формочки делаются, например, через функцыи, осуществоляющие маппинг RDBMS<->control value (притом в большынстве случаев используется code reuse вовсю) и DSL, накидывающий оные функцыи и организующий layout. Есть и другие варианты -- но класс на таблицу -- это тот самый, вредный, тупой, кривой ORM, притом самописный и методом заката солнца вручную.
no subject
no subject
no subject
Конечно, нет. MVC -- это вообще маразм и средство переусложнения систем. Все viewerы должны взаимодействовать только чрез model, по очевидным причинам.
MVC в настольном WIMP GUI -- это вдвойне маразм, поскольку разделять view и control на одном экране, с которым работает один отдельный пользователь -- это шызофрения.
no subject
Конечно, нет. MVC -- это вообще маразм и средство переусложнения систем. Все viewerы должны взаимодействовать только чрез model, по очевидным причинам.
Ничего не понял. Можно не знаю там со ссылками и примерами?
MVC в настольном WIMP GUI -- это вдвойне маразм, поскольку разделять view и control на одном экране, с которым работает один отдельный пользователь -- это шызофрения.
А я где-то говорил про desktop? :) Я больше про веб говорю. Там эта концепция вполне себе живет.
no subject
> которая осуществляет маппинг RDBMS<->control value и
> DSL.
Вы так говорите, будто эти MVC-поделки пишутся не веками и валятся не раз в день.
> В большинстве процентов случаев форма
> соответствует записи в таблице на 100%.
У меня это редкость.
Но когда случается -- такая форма состоит из строк из 1.2 строки на поле: одна задаёт вид контрола, одна/пятая определяет его порядок в output grid.
no subject
Вы так говорите, будто эти MVC-поделки пишутся не веками и валятся не раз в день.
Вы не поверите, но именно так. И пишутся быстро и валятся не раз в день ;)
У меня это редкость. Но когда случается -- такая форма состоит из строк из 1.2 строки на поле: одна задаёт вид контрола, одна/пятая определяет его порядок в output grid.
А у меня вот увы нет. Опять же там пачка валидирующего кода вылазит и т.п.