ну тогда вопрос исчерпан, это не DM
-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
Модели в фреймворках
- Автор темы StalkerClasses
- Дата начала
если написать глупый маппер, типа $stmt->fetchObject(UserProfile::class); то вопрос сводится к "сколько запросов и сколько сущностей"
В _идеале_ у тебя один волшебный маппер, который любую write-model умеет сохранить сам, куда нужно.
На практике, ты скорее всего будешь иметь по одному мапперу на каждое действительно _сложное_ представление, и какой-нибудь автомаппер для простых сущностей c простыми связями.
Это я Фанату отвечал на его вопрос пару страниц назад.
Иногда можно сфинксом-эластиком. Но далеко не всегда. Это оптимизация, +1 SPOF, +1 сервис к настройке-поддержке-мониторингу, +1 технология к изучению команде. В крупном проекте пол-года разрешение получать и со всеми согласовывать. Базовое решение такой задачи в общем случае - SQL, и это работает.
@fixxxer скажи, я не сильно наврал здесь? https://qna.habr.com/answer?answer_id=1524891#answers_list_answer
И это, я всё ещё надеюсь что ты расскажешь, где я наврал в "A standalone QB without ORM indeed has a very little use.".... (смущённый смайлик)
И это, я всё ещё надеюсь что ты расскажешь, где я наврал в "A standalone QB without ORM indeed has a very little use.".... (смущённый смайлик)
Вроде не сильно.
Можно в первом приближении сказать, что, OLTP - это как раз персистенция write models, а OLAP - это read models.
Возьмем для примера с одной стороны вырожденную, но с другой стороны постоянно встречающуюся на практике задачу. В базу пишутся всякие там события, и есть приложение, которое по этим событиям выводит всякую статистику. Daily/monthly active users, кол-во регистраций, покупок итд.
Когда мы пишем событие в базу, мы даже не задумываемся о том, что в bounded context-е статистики/аналитики событие - это сущность предметной области. Это настолько простая сущность, что ее зачастую даже не оформляют как сущность, и уж до ORM точно дело не доходит, нафига оно тут, если все решается банальным insert-ом. А когда мы строим всякие там запросы, по которым рисуем красивые графики и таблички, там у нас совсем другие read models, типа "количество активных пользователей за некий период", и чтобы построить запросы со всеми этими group by и order by, query builder нам очень пригодится (особенно если на входе аргументы типа за какой период нам оно надо, или фильтры типа "только для пользователей, купивших премиум-тариф"), а никаким ORM тут не пахнет.
Тут разделение read и write настолько очевидно, что над ним никто даже не задумывается. А если задуматься, это различие есть почти всегда.
Грубо говоря, ORM - для OLTP, QB - для OLAP.
Можно в первом приближении сказать, что, OLTP - это как раз персистенция write models, а OLAP - это read models.
Возьмем для примера с одной стороны вырожденную, но с другой стороны постоянно встречающуюся на практике задачу. В базу пишутся всякие там события, и есть приложение, которое по этим событиям выводит всякую статистику. Daily/monthly active users, кол-во регистраций, покупок итд.
Когда мы пишем событие в базу, мы даже не задумываемся о том, что в bounded context-е статистики/аналитики событие - это сущность предметной области. Это настолько простая сущность, что ее зачастую даже не оформляют как сущность, и уж до ORM точно дело не доходит, нафига оно тут, если все решается банальным insert-ом. А когда мы строим всякие там запросы, по которым рисуем красивые графики и таблички, там у нас совсем другие read models, типа "количество активных пользователей за некий период", и чтобы построить запросы со всеми этими group by и order by, query builder нам очень пригодится (особенно если на входе аргументы типа за какой период нам оно надо, или фильтры типа "только для пользователей, купивших премиум-тариф"), а никаким ORM тут не пахнет.
Тут разделение read и write настолько очевидно, что над ним никто даже не задумывается. А если задуматься, это различие есть почти всегда.