Модели в фреймворках

флоппик

promotor fidei
Команда форума
Партнер клуба
И главный вопрос - а мапперов сколько? Скажем, нам нужно 3 читательских модели. Сколько мапперов нам надо? Нутром чую что три.
Или ок, read aside, если у нас две write модели, то получается и два маппера?
В _идеале_ у тебя один волшебный маппер, который любую write-model умеет сохранить сам, куда нужно.
На практике, ты скорее всего будешь иметь по одному мапперу на каждое действительно _сложное_ представление, и какой-нибудь автомаппер для простых сущностей c простыми связями.
 

grigori

( ͡° ͜ʖ ͡°)
Команда форума
Ну как всегда, не читаем что пишут другие.
Во первых я ничего не писал насчет доктрины. Доктрина не совсем подходит для чтения - из нее вообще не выпилять часть связанную с записью (да и вообще разработчики доктрины давно перестали понимать как и что у них работает внутри)
Это я Фанату отвечал на его вопрос пару страниц назад.

здесь вообще надо бы сфинкс или эластик использовать. Везде в примерах было тупое ->load($id) такие единичные загрузки со всеми (или не всеми если надо) зависимостями встречается очень часто. И если говорить о сложных выборках списков, то в большинстве случаев сначала сложным запросом (или сфинксом или эластиком) получить список id, а потом по этим id подгрузить все данные с зависимостями.
Иногда можно сфинксом-эластиком. Но далеко не всегда. Это оптимизация, +1 SPOF, +1 сервис к настройке-поддержке-мониторингу, +1 технология к изучению команде. В крупном проекте пол-года разрешение получать и со всеми согласовывать. Базовое решение такой задачи в общем случае - SQL, и это работает.
 

fixxxer

К.О.
Партнер клуба
Вроде не сильно.

A standalone QB without ORM indeed has a very little use
Грубо говоря, 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 настолько очевидно, что над ним никто даже не задумывается. А если задуматься, это различие есть почти всегда.
 
Сверху