у списка товаров?

ты же сам сказал

скидки применяются на этапе формирования заказа

список продуктов - список продуктов

ты выбираешь продукты и из них формируешь заказ

то есть список продуктов как был простым так и остается, нет?)

Т.е. ты предлагаешь писать бэкенд на sql?

Т.е. ты предлагаешь писать бэкенд на sql?

предлагаю вводить read model

где-то это тупо sql

где-то агрегации из эластики

где-то - обвязка над orm потому что было впадлу

то есть список продуктов как был простым так и остается, нет?)

ну вообще-то скидки должны еще на витрине отображаться (сисок наш), и там к примеру учитывать что ты уже в корзину добавил

Как понять границы "где-то"?

но наверно мы про другое

ну вообще-то скидки должны еще на витрине отображаться (сисок наш), и там к примеру учитывать что ты уже в корзину добавил

скидки на уровне "купи две штуки получи третью в подарок, или если это третья штука такая-то то 30% скидка на все"

а не "сегодня у нас скидки для всех продуктов 30%" да и такие вещи можно легко делать через sql

никому не интересно подумать в эту сторону?

ибо лично меня задолбало писать мэпперы поверх мэпперов

хотя я могу просто сделать sql запрос, и жахнуть результат в json например

CQRS и все такое

Интересно подумать в эту сторону, но мало подумать, ещё подумать придётся как проверить подуманное и как всех заставить взять это новое подуманное, если получится.

это не новое, говорю ж - CQRS

тут вопрос как это делать удобнее

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

есть кучи read реплик, и мне надо сделать так что бы все операции на чтение выполнялись на них, а все операции на запись - на master реплике

вот и задумался "а нафига мы вообще так делаем что потом страдаем... ненужная же работа"

жирнющая ORM что бы показать список категорий - регулярно такое в проектах вижу

или примитивный active record что бы делать мега сложную логику - тоже популярная тема)

жирнющая ORM что бы показать список категорий - регулярно такое в проектах вижу

я просто не понимаю

вот у тебя есть орм

ты делаешь на ней сложные штуки, у тебя маппинги все есть, все хорошо, а потом тебе надо сделать простую выборку и ты жмяк и в обход орм начинаешь что-то выдумывать?)

именно так

не факт что в обход ORM, например у меня есть Doctrine - скорее всего я сделаю DQL запрос и просто сделаю выборку не в сущность а в массивчик

простые списки это покрывает идеально

списки чуть сложнее - уже не так удобно

вот сижу и балуюсь с такими

не факт что в обход ORM, например у меня есть Doctrine - скорее всего я сделаю DQL запрос и просто сделаю выборку не в сущность а в массивчик

ну это нормально, но если у тебя просто вывести список N-ой сущности, getRepo.findAll наверно проще будет, чем писать dql запрос?)

> getRepo.findAll наверно проще будет, чем писать dql запрос?) SELECT p FROM Posts LIMIT 20;

но зато не надо в сущности писать лишние геттеры которые нужны тупо для того что бы сформировать json

сущности вообще не будут иметь ничего что нужно исключительно для view layer

а это уже значительно меньше кода

то есть количество кода сильно не меняется - меняется где он лежит

а я думал это контроллер решает в чем отдать твой список

причем тут сущность

эм....

ты получил список сущностей

как ты из него получишь json?

допустим у тебя в сущностях нет геттеров от слова вообще

тебе придется их написать?

и они будут использоваться только для того что бы сформировать json?

ну то есть либо у тебя в сущностях будет код который нужен только для view layer либо ты просто будешь получать уже готовые данные которые будешь кидать в json

не понимаю что за геттеры) ну в смысле, доступ к данным объекта? getId...

не понимаю что за геттеры) ну в смысле, доступ к данным объекта? getId...

да, нет доступа

или что?)

ну то есть все данные приватны, никакого способа до них добраться сейчас нет (потому что для операций записи они не нужны)

да, нет доступа

а зачем тогда они вообще нужны такие?))

а зачем тогда они вообще нужны такие?))

кто "они"?

сущности

сущности без геттеров?)

угу

или у тебя исключительно сеттеры?)

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

> или у тебя исключительно сеттеры?) нет ни сеттеров (привычных в духе setSomething) ни геттеров

есть методы с поведением

ООП же

класс тупо из геттеров и сеттеров - это как структура данных.

это не объект

там нет инкапсуляции

я ооп то не знаю, пишу процедуры в классы обернутые, пришел к вам, научится)

а ну вот тип того

короч предположим что геттеры и сеттеры не нужны

вообще

например если тебе надо получить id сущности вместо getId() ты пишешь toId()

метод который сконвертирует объект в другую хрень - ее айдишник

угу

другая семантика, хотя по коду будет казаться что одно и то же

у тебя будет toJson

это один из вариантов как не делать геттеры)

и честно - я им пользуюсь

только toArray а не toJson