LINUX.ORG.RU

ORM internals:View from within

 , , ,


0

1

В очередной раз хочу заняться изучением Laravel.

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

Во внутрянку Eloquent ORM пока лезть не хочу, т.к. боюсь запутаться.

Хотя вот — https://pic4a.ru/02/6tz.jpg ,может бояться не нужно)

★★★★★

@deep-purple

@no-such-file

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

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

Twissel ★★★★★ ()
Последнее исправление: Twissel (всего исправлений: 1)

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

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

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от Twissel

Ась?

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

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

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

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

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

deep-purple ★★★★★ ()
Последнее исправление: deep-purple (всего исправлений: 1)
Ответ на: комментарий от deep-purple

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

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

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

no-such-file ★★★★★ ()
Последнее исправление: no-such-file (всего исправлений: 1)

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

goingUp ★★★★★ ()
Ответ на: комментарий от deep-purple

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

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

goingUp ★★★★★ ()
Ответ на: комментарий от goingUp

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от no-such-file

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

goingUp ★★★★★ ()
Ответ на: комментарий от no-such-file

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

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

$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]);
Ну да, синтаксис запроса не везде подсветит.

deep-purple ★★★★★ ()
Ответ на: комментарий от goingUp

А как же MVC?

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

deep-purple ★★★★★ ()
Ответ на: комментарий от goingUp

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

Аргументы?

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

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

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

goingUp ★★★★★ ()
Ответ на: комментарий от goingUp

А как же MVC?

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

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

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

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

deep-purple ★★★★★ ()
Ответ на: комментарий от goingUp

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

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

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

no-such-file ★★★★★ ()
Ответ на: комментарий от deep-purple

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

goingUp ★★★★★ ()
Ответ на: комментарий от no-such-file

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

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

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

goingUp ★★★★★ ()
Ответ на: комментарий от deep-purple

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

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от goingUp

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

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

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

deep-purple ★★★★★ ()
Ответ на: комментарий от goingUp

Ну или модель

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

no-such-file ★★★★★ ()
Ответ на: комментарий от no-such-file

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

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

deep-purple ★★★★★ ()
Ответ на: комментарий от no-such-file

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

goingUp ★★★★★ ()
Последнее исправление: goingUp (всего исправлений: 1)
Ответ на: комментарий от goingUp

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

deep-purple ★★★★★ ()
Ответ на: комментарий от goingUp

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

no-such-file ★★★★★ ()
Ответ на: комментарий от goingUp

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

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

no-such-file ★★★★★ ()
Ответ на: комментарий от deep-purple

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

Twissel ★★★★★ ()
Ответ на: комментарий от Twissel

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

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

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

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

this

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

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

Twissel ★★★★★ ()
Ответ на: комментарий от Twissel

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

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

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

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

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

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

deep-purple ★★★★★ ()
Ответ на: комментарий от deep-purple

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

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

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

alexmaru ()
Ограничение на отправку комментариев: только для зарегистрированных пользователей