Comments 13
В реальной жизни схемы баз данных — на полстены. Или на всю стену. Как повезёт. И запросы к ним — на сотни строк SQL-кода. Интересно, как в таких бесчеловечных условиях будет работать Eloquent ORM?
Вообще, конечно, мне кажется, ORM-проблема решения пока что не имеет. Если посмотреть в корень неприятностей (иногда не нужно отказывать себе в удовольствии это делать), то можно заметить, что в основе реляционных БД лежит математика, а конкретно исчисление предикатов, а в основе ООП не лежит ничего кроме интуитивно как-бы понятных, но абсолютно никак не формализованных утверждений, в большинстве своём слепо принимаемых на веру и служащих поводом для безысходных холиваров. ORM — это, по сути, мэппинг математики на лирику. Для того, чтобы одно с другим качественно единообразно поженить, видимо, нужно или положить ООП на математическую основу (за полвека это не удалось, и перспектив не очень видно), или выкинуть из реляционных баз идейную основу и превратить их в болото (NoSQL?).
Вообще, конечно, мне кажется, ORM-проблема решения пока что не имеет. Если посмотреть в корень неприятностей (иногда не нужно отказывать себе в удовольствии это делать), то можно заметить, что в основе реляционных БД лежит математика, а конкретно исчисление предикатов, а в основе ООП не лежит ничего кроме интуитивно как-бы понятных, но абсолютно никак не формализованных утверждений, в большинстве своём слепо принимаемых на веру и служащих поводом для безысходных холиваров. ORM — это, по сути, мэппинг математики на лирику. Для того, чтобы одно с другим качественно единообразно поженить, видимо, нужно или положить ООП на математическую основу (за полвека это не удалось, и перспектив не очень видно), или выкинуть из реляционных баз идейную основу и превратить их в болото (NoSQL?).
А что за проблема с ОРМ? ОРМ — это решение проблемы связи объектов на рсубд и обратно.
ОРМ — это решение проблемы связи объектов на рсубд и обратно.Точная, короткая, но ёмкая формулировка.
К сожалению многие (включая автора данной статьи) видят в ОРМ просто новый уровень абстракции для замены синтаксиса SQL запросов.
Мы прошли долгий путь, с тех дней когда мы в ручную писали SQL запросы в наших веб приложения. Инструменты, такие как Laravel’ий Eloquent ORM позволяют нам работать с базой данных на более высоком уровне, освобождают нас от деталей более низкого уровня — таких как синтаксис запросов и безопасность.Поэтому понятно непонимание maslyaev
В реальной жизни схемы баз данных — на полстены. Или на всю стену. Как повезёт. И запросы к ним — на сотни строк SQL-кода. Интересно, как в таких бесчеловечных условиях будет работать Eloquent ORM?А никак. Кмк ОРМ предназначен для решения совсем другого класса задач.
Говорим "ORM" подразумеваем "DBAL"? Тогда понятнее.
Я вам страшное скажу, ORM вообще не отвечает непосредственно за SQL запросы. Она их мапит на объектную модель.
Те кто пропагандируют отказ от ORM из за SQL генератора кажется этого не понимают. Никто не запрещает писать запросы в 100 строк чистого SQL и использовать ORM
UFO just landed and posted this here
Я именно так и пишу и почему-то всё синхронизруется. Наверное, потому, что я об этом позаботился хотя бы одной строчкой кода типа $user->save() (или даже $this->save() в методе User::withdrawMoney() ) при использовании каких-то AR без UoW или типа $om->flush(); при использовании UoW. Причём в последнем случае сохранение можно сделать автоматическим где-то в shutdown обработчике.
Или вы про конкретные примеры в посте?
UFO just landed and posted this here
у вас состояние модели может быть неактуальным
Есть транзакции с различными видами блокировок. Но, вообще, да, универсальные ОРМ плохо работают, если хочется заметную часть логики перенести в РСУБД. Выхода четыре основных:
- не переносить
- отказаться от ОРМ в принципе, то есть от проецирования реляционной модели на объектную, скорее всего за счёт отказа от объектной, ну или от реляционной :)
- разработать свою ОРМ, хорошо знающей о логике в РСУБД. Или доработать универсальную.
- изменить обе модели так, чтобы маппинг проблем не создавал особых, например путём перехода к EventSourcing, где маппиться будут не сущности, а события, а на стороне СУБД например триггерами формироваться проекции сущностей.
Если совсем по-простому: реляционный подход и объектный не совместимы между собой в самой своей сути, поэтому приходится каждый раз изобретать велосипед, лепить тысячи заплаток и подставлять костыли там, где норовит упасть. Единственно верного подхода к решению этой задачи нет и не может быть.
Естественно, в каждом конкретном случае мы выкручиваемся. При помощи велосипедов, заплаток, костылей и километров говнокода. Системы создаются, эксплуатируются, развиваются. Всё в порядке. Но когда выкатывают очередную «серебряную пулю» и говорят, что она легко лечит тот геморрой, который уже десятки лет не смог вылечить никто, да ещё и иллюстрируют примерами детсадовского уровня — вот это реально бесит.
Мы знаем, что такое в РСУБД таблица, строка, колонка, ячейка, первичный ключ, внешний ключ. Все эти понятия имеют чёткую математическую интерпретацию, и поэтому реляционная алгебра — это именно алгебра, а не искусствоведение или, например, политология. Можно ли что-то подобное сказать про ООП? Неа, нельзя.
Что такое объект? Что такое класс? Что значит «потомок класса»? Можно ли от этих терминов протянуть понятийный мостик, к чему-то математическому? Можно попытаться сказать, что класс — это множество, объект — его элемент, а потомок — это подмножество. Но дальше начинаются чудеса. Например, обнаруживается, что массив объектов — это тоже множество. «Массив» и «класс» — ну совсем разные вещи, но они обе типа про множества. Или вдруг выясняется, что в ООП объект может принадлежать только одному классу (и транзитивно его предкам через наследование). А теория множеств такого ограничения не предполагает никак. Там вполне нормальна ситуация, когда «существуют мюмзики которые также являются лямзиками, а некоторые лямзики не являются мюмзиками», и при этом никаких ограничений на то, что эти же объекты заодно могут быть бумзиками и грумзиками. В ООП такие ситуации реализуются через чрезвычайно уродливую миксинную технологию (паттерн «стратегия»), но это иначе как архитектурным костылём язык не поворачивается назвать. Короче, нет никакой внятной идейной основы у ООП, и поэтому ОО-программрование ближе к искусству и политологии, чем к нормальной инженерии.
Искусство с искусством (например, музыку с литературой) правильно поженить можно, науку с наукой — тоже, но совмещать несовместимое без велосипедов и костылей — никак.
Естественно, в каждом конкретном случае мы выкручиваемся. При помощи велосипедов, заплаток, костылей и километров говнокода. Системы создаются, эксплуатируются, развиваются. Всё в порядке. Но когда выкатывают очередную «серебряную пулю» и говорят, что она легко лечит тот геморрой, который уже десятки лет не смог вылечить никто, да ещё и иллюстрируют примерами детсадовского уровня — вот это реально бесит.
Мы знаем, что такое в РСУБД таблица, строка, колонка, ячейка, первичный ключ, внешний ключ. Все эти понятия имеют чёткую математическую интерпретацию, и поэтому реляционная алгебра — это именно алгебра, а не искусствоведение или, например, политология. Можно ли что-то подобное сказать про ООП? Неа, нельзя.
Что такое объект? Что такое класс? Что значит «потомок класса»? Можно ли от этих терминов протянуть понятийный мостик, к чему-то математическому? Можно попытаться сказать, что класс — это множество, объект — его элемент, а потомок — это подмножество. Но дальше начинаются чудеса. Например, обнаруживается, что массив объектов — это тоже множество. «Массив» и «класс» — ну совсем разные вещи, но они обе типа про множества. Или вдруг выясняется, что в ООП объект может принадлежать только одному классу (и транзитивно его предкам через наследование). А теория множеств такого ограничения не предполагает никак. Там вполне нормальна ситуация, когда «существуют мюмзики которые также являются лямзиками, а некоторые лямзики не являются мюмзиками», и при этом никаких ограничений на то, что эти же объекты заодно могут быть бумзиками и грумзиками. В ООП такие ситуации реализуются через чрезвычайно уродливую миксинную технологию (паттерн «стратегия»), но это иначе как архитектурным костылём язык не поворачивается назвать. Короче, нет никакой внятной идейной основы у ООП, и поэтому ОО-программрование ближе к искусству и политологии, чем к нормальной инженерии.
Искусство с искусством (например, музыку с литературой) правильно поженить можно, науку с наукой — тоже, но совмещать несовместимое без велосипедов и костылей — никак.
я для Eloquent ORM сделал надслойку где в модели в конструкторе (ну или где то еще, но удобнее там) описывается схема (вот прям select) полей, споддержкой переименовывания на лету, так же описывались поля с функциями сереализации/десереализации, записывались отношения( join таблиц как моделей) и все это ради того что бы получить list/item, а самое главное, одним ajax запросом создать или изменить данные в этой модели с автоматической раскладкой данных по зависимостям. Причем поддерживались как One2One, так и One2Many.
А учитывая что как субд использовался постгрес, то кастомный select решал. Ну и я опустил подробности допуска к полям и моделям ролей на чтение/запись. По факту у меня получился конструктор, которому не хватает визуального редактора схемы. и к этому конструктору шел фронт на Backbone, который так же по сути состоял из кирпичиков… И там были только UCollection и UModel для загрузки/обновления данных через описаный выше метод.
А учитывая что как субд использовался постгрес, то кастомный select решал. Ну и я опустил подробности допуска к полям и моделям ролей на чтение/запись. По факту у меня получился конструктор, которому не хватает визуального редактора схемы. и к этому конструктору шел фронт на Backbone, который так же по сути состоял из кирпичиков… И там были только UCollection и UModel для загрузки/обновления данных через описаный выше метод.
Используйте ORM для CRUD. А для всего остального QueryBuilder.
Sign up to leave a comment.
Расширение моделей в Eloquent ORM