ORM internals:View from within

http://bit.ly/322o0Im

Ну лучший не значит простой, но здесь должно быть кое-что полезное

deep-purple

no-such-file

Меня интересует из каких структурных частей состоит ORM, для начала.

Под структурными частями подразумеваются все эти сущности, состояния, репозитории и их взаимосвязи между собой.

может бояться не нужно

Боятся не нужно, там внутри никакого рокет сайнс нет. Хотя там конечно ехала фабрика через фабрику, но это уже другой вопрос.

чтобы можно было понять, как это устроено изнутри

Книжку Мэтта Зандстры читал? Там как бы есть отдельная глава Database patterns где всё это разбирается.

Ась?

Да хрен его знает — каждый кто во что горазд лепит. В первом зенде, помню, писали эти взаимосвязи прямо в классах моделей. А вот щас я в доктрину заглянул — для описания взаимосвязей к тупым классам «моделей» у которых только геттеры и сеттеры есть (ну структуры же!), которые будут заполняться через абтракцию над БД, предлагают XML писать.

И вот я сначала взоржал, а потом задумался, а теперь вообще грустно стало. Это же тричетырнадцатьдец.

Вот что бы я когда-либо не делал — всегда хватало одного только квери-билдера. Ну серьёзно. Ах, да — ORM нужно было только для создания/редактирования какой-то сущности. Все остальные кейсы, а это 99% (фильтры, агрегация, сортировка) — квери-билдер. Так что мешает и сущности отредактировать только с помощью одного квери-билдера?

Ой, вэй, я ще больше скажу — квери-билдер тоже в хер не впился, ибо, подумать, как часто (не переписывая проект полностью) ты одну базу данных менял в проекте на другую (например, мускуль на посгре)? Да — загляни в сорцы ЛОРа.

... меня походу Эдик покусал ...

квери-билдер тоже в хер не впился

Это ты зря. Билдер нужен не для того чтобы менять базу (для этого-то он действительно в хер не впился, так и так страдать), а для того чтобы удобно было запросы собирать (внезапно). Т.е. часто бывает что нужно добавить-выкинуть какие-то условия или сделать-неделать джойны и т.п. и руками строки клеить для этого слишком уныло.

А на счёт ORM я согласен, в вебе по большому счёту не нужно.

Гугли паттерн ActiveRecord, Eloquent это оно и есть.

Ах, да — ORM нужно было только для создания/редактирования какой-то сущности.

А как же MVC? ОП вобщем хочет изучать Laravel, а он подразумевает, что будет модель.

подразумевает, что будет модель

И как это связано с ORM? Только так что в качестве модели можно использовать объекты ORM. А можно не использовать.

Ну если есть БД, то удобнее таки использовать ORM.

добавить-выкинуть какие-то условия или сделать-неделать джойны, руками строки клеить

Что мешает писать «одной» строкой форматируя?

$result = $db->query('
    SELECT
            a.x/*,
            b.y*/
        FROM a
        /*LEFT JOIN b
            ON b.a_id = a.id*/
        WHERE a.id = :id
', ['id' => 1]);

А как же MVC?

Что мешает заполнять модели квери-билдером?

Ну если есть БД, то удобнее таки использовать ORM.

Аргументы?

Что мешает заполнять модели квери-билдером?

Но зачем, если можно взять ORM и он будет заполнять. Еще их нужно сохранять, выбирать связанные объекты.

А как же MVC?

Что мешает заполнять модели квери-билдером?

Не, я ещё дополню.

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

Прикинь. Ты у моделей не только будешь не нужные им в этом месте взаимосвязи описывать, но и будешь вынужден потратить больше памяти на обращение к этому экшну. Должен будешь преобразовать из моделей внутреннего представления в представление для вывода жссоном. А так, ты делаешь прямо означающий запрос что отфильтровать, как отсортировать, какие поля достать и сразу результат (массив объектов, возможно пустой) вывалить в ответ на запрос.

Ну блин, реально, ехала фабрика через фабрику. Всё это можно сделать проще и эффективнее.

Ты не понял. Я имел в виду динамически во время работы запроса, в зависимости от переданных параметров.

Ну для простого случая может и ок, но потом тебе понадобится для формирования джейсон использовать какие-то методы модели, и здравствуй копипаста. Например из трех полей сделать ФИО.

Дык. Так и так внутри if-а же конкатенировать тем или иным способом.

Например из трех полей сделать ФИО

Хелпер.

Ну или модель, а вместо склеивания SQL - квери билдер)

Так и так внутри if-а же конкатенировать тем или иным способом

Не совсем. При склейке руками нужно следить чтобы запрос не ломался в любых комбинациях. Простейший пример - запрос где может быть 0, 1 или 2 условия в where. Т.е. если условия есть нужно добавлять where, если есть первое условие то перед вторым нужен and, и т.д. В сложных запросах получается жуткая лапша. Либо ты просто сделаешь билдер на коленке.

Кроме того билдер можно расширять своими элементами, которые будут внутри прятать всю логику. Это тоже важно, т.к. те же джойны часто повторяются (нужно джойнить определённую таблицу по одному и тому же условию).

Зачем писать в одной модели сто хелп-методов для ста мест?

а вместо склеивания SQL - квери билдер

А мы с тобой не это обсуждаем.

Ну или модель

Разумеется модель. Только ещё раз, ORM тут при чём? Мне кажется ты путаешь тёплое с мягким.

В сложных запросах получается жуткая лапша. Либо ты просто сделаешь билдер на коленке.

Ниет, тут я напишу три отдельных целых (под)?строки на все три случая для «0, 1 или 2 условия в where» и в каждом из случаев буду использовать (подставлять в основной) нужную. Короче, изголиться можно. Но ты сейчас скажешь что проще не изголяться, а я опять частично соглашусь, ведь удобство квери-билдера я не отрицаю.

Ну ок, допустим есть задача на api запрос выплюнуть джейсон с id юзера и ФИО. Юзер лежит в БД, три поля под имя, фамилию, отчество. Как бы ты сделал это с моделью без ОРМ?

А можно я сделаю это без модели?

Кто ж тебе запретит)

Ну так носучфайл и с моделью и без орм это сделает — ему ж тоже не запрещает ничто и никто. Вот почему тебе что-то запрещает?

А мне нравится с моделью и с ОРМ)

Берём пользователей через DAL результат в виде массива, суем в сериализатор, который вообще отдельная сущность (если она у тебя в модели, иди учи SOLID).

А где будет находиться код формирования ФИО?

где будет находится код формирования ФИО?

Целых три варианта: в самом запросе к БД (т.е. фактически в DAL), в сериализаторе пользователя, в отдельном мутаторе данных. При этом можно даже сделать формальное описание запроса в виде цепочки получения данных, трансформации, сериализации. Добро пожаловать в программирование на YAML (в духе XSLT, но с человеческим лицом и под твою задачу).

Да, бытует мнение, что ORM придумали для этнических индусов, которые не осилили SQL, а код писать как-то надо)

С интересом наблюдаю за дискуссией.

Она уже закончилась, вроде как.

Ну так вопрос на повестке у тебя какой? Ларавель? ОРМ? Поковырять чтобы знать как работает?

Поковырять чтобы знать как работает?

this

Ну no-such-file уже ответил, что Мэтт Зандстра или как его там курить…

смотрел я когда-то это книгу, но давно это было 8 лет назад где-то ;-)

Я нашел вот такую шляпу https://nextras.org/orm/docs/3.1/ .

Не могу судить насколько качественный код, что скажешь?

Код нормальный вроде. Но...

1) Не знаю что у него там, но это не PSR.

2) Где у самого то комментарии в формате пхп-док? Как он ориентируется в этих своих классах без документации?

3) Велосипед-парсер из кучи классов. Парсит, кеширует куда-то комментарии из текста перед определением твоих энтитей. Вроде и сделал удобно, но такой ценой, что мама дорогая. И не понятно чего достиг. Проще было бы в самом классе определить протектед массив и написать его валидацию в базовом классе энтити, а не делать закат солнца вручную.

Ну так, навскидку и по быстрому.

Нет, лично мне не нравится. Уж если брать, то реально доктрину там, зенд, ларавель. Ну короче пусть и сильно жирное, но серьёзное, чтобы был не велосипед, а с размахом — танк на педально-цепной тяге — энтерпрайзненько!

А вот щас я в доктрину заглянул — для описания взаимосвязей к тупым классам «моделей» у которых только геттеры и сеттеры есть (ну структуры же!), которые будут заполняться через абтракцию над БД, предлагают XML писать.

не неси бред. То что пишется в xml - можно так же с успехом писать а аннотациях. А там лишь пишутся инструкции для базы данных. Зачем это делается? чтобы ты мог создать по этим параметрам базу данных прямо из файлов, или сгенерировать миграцию. Там три билдера в комплекте идут, UI: один для создания/редактирования новой entity, другой для создания миграции, и третий - синхронизирует изменения в базу данных по файлам миграций.

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