ну либо да - рефлексией - нафиг геттеры

мне кажется неправильным формировать json из сущностей.

Да, я понимаю. Потому хотел из сущности построить какое-то ДТО и из него строить ответ.

ну вот смотри. ты достаешь из базы сущность, потом конвертишь ее в DTO, потом конвертишь ее в json

причем в 90% случаев структура в целом не меняется

а значит можно было бы просто сделать select и запихнуть массивчик в json

минуя всякие промежуточные этапы. да даже array hydrator для простых случаев норм

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

ну тут правда еще и доктрина палки в колеса вставляет

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

Да И я не хочу так делать.

Но тогда будет маппер, который все знает о сущности. Разве это не грязь?

а почему это грязь? вопрос кто от кого зависит)

мэппер знает все о сущности, сущность ничего не знает о мэппере)

а почему это грязь? вопрос кто от кого зависит)

Ага. Логично. И не страшно, что рефлексия, на твой взгляд?

да. там выходит очень жесткая связанность но в целом в определенных условиях это лучшее что можно придумать

минуя всякие промежуточные этапы. да даже array hydrator для простых случаев норм

а если в сущности данные, но отображать надо результаты работы методов сущности?

Ага. Логично. И не страшно, что рефлексия, на твой взгляд?

ммм... и да и нет)

вопрос в обратной совместимости)

а если в сущности данные, но отображать надо результаты работы методов сущности?

значит у тебя сущность отвечает за UI логику

а почему это грязь? вопрос кто от кого зависит)

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

вопрос в обратной совместимости)

Мне не требуется :)

а в чём проблема геттеров, если они используются только для ui? проблемы начинаются тогда, когда например вместо $user->canSubscribe($podcast) пишут $user->getSubscriptions()->count() < 3, тогда изменения требований по подписке приведут к необходимости менять больше кода, чем если бы это было без геттеров. то есть проблема в том, что мы забираем какие-то данные через геттер и уже сами решаем какую логику на основе этих данных строить.

а в чём проблема геттеров, если они используются только для ui? проблемы начинаются тогда, когда например вместо $user->canSubscribe($podcast) пишут $user->getSubscriptions()->count() < 3, тогда изменения требований по подписке приведут к необходимости менять больше кода, чем если бы это было без геттеров. то есть проблема в том, что мы забираем какие-то данные через геттер и уже сами решаем какую логику на основе этих данных строить.

если только для UI - нет проблемы

просто смысла тоже не особо много

значит у тебя сущность отвечает за UI логику

ну вот тут-то cqrs и пригодится

ну вот тут-то cqrs и пригодится

главное понимать что cqrs это оч простая штука.

просто 2 интерфейсика а не один. вот и вся разница

а то многие почему-то начинают обмазываться command bus-ами всякими

хотя это не обязательно

да, данные даже физически в одном месте могут быть

а то многие почему-то начинают обмазываться command bus-ами всякими

а я просто пока не знаю что это такое, наверное поэтому ещё не обмазался :D

именно, суть в том что разграничения на уровне выше, то есть у тебя свобода появляется где чего делать

но вообще я бы рассмотрел такой вариант как... для UI просто сделать вьюшек в базе и заэкспоузить это дело через какой PostgREST/postgrest

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

@fes0r а как сделать прямо по уму? То есть, пусть у меня сущности с большим количеством логики. И при отдачи данных, их вид сильно отличается от сущностей. Что делать в такой ситуации? Рефлексия?

@fes0r а как сделать прямо по уму? То есть, пусть у меня сущности с большим количеством логики. И при отдачи данных, их вид сильно отличается от сущностей. Что делать в такой ситуации? Рефлексия?

вьюшки в базе)

я серьезно чет подсел на вьюшки в последнее время)

То есть просто продублировать данные?

да, можно так.

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

у меня ивент серсинги всякие и я могу проекций наделать как захочу

вьюшки в целом тоже довольно легко делаются

Ага. У меня просто сейчас сущность, связи там. Есть сервисы, которые данные готовят. Но хочется как-то иначе.

вьюшки в целом тоже довольно легко делаются

С доктриной? Или отдельно мигрируешь?

Делаешь RO?

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

Интересно

есть в чате сисадмины? вопрос по linux есть

С доктриной? Или отдельно мигрируешь?

доктрина не умеет во вьюшки. Да даже dbal - он умеет вьюшки из базы в схему забирать, но не умеет описывать на уровне схемы

есть в чате сисадмины? вопрос по linux есть

rm -rf

доктрина не умеет во вьюшки. Да даже dbal - он умеет вьюшки из базы в схему забирать, но не умеет описывать на уровне схемы

Вот я тоже не видел. Потому и интересно

Вот я тоже не видел. Потому и интересно

а там тупняк

Поверх сущности пишешь или dbal?

https://github.com/doctrine/dbal/pull/2510

Поверх сущности пишешь или dbal?

dbal

dbal

Круто

Интересно было бы глянуть

https://gist.github.com/fesor/0d5ecf0afc638c7870272ead20614681

если не видел

Ибо в моих проектах люди тупоааты

все что нужно знать о том как начать юзать просто dbal в проектах на симфони) точнее то почему это не юзают)

rm -rf

без sudo не так интересно

https://gist.github.com/fesor/0d5ecf0afc638c7870272ead20614681

Найс

если нагенеришь вопросов - расширю статью. я эту хрень за пару минут накидал в ответ на коммент вида "юзаю ORM только что бы миграции генерились"

На самом деле очень классно читать твое и Макса мнения. Со статьями беда в том, что не пощуать репы очень часто. Интересно было бы посмотреть как со вьюшками работаете в рамках сущностей. Как Сагу реализуете. Я блин стараюсь, читаю статейки, но пока прикладной задачи с ок бюджетом не будет не уверен, что правильно понимаю

Очень многие освещаемые тут вопросы интересно увидеть на "живом" примере

1. имхо вьюшки работают либо если у тебя круд + простые агрегации, либо если у тебя какой-нибудь es или подобное, где нужно проекции делать собирать в них какие-то сложные данные как по мне не айс

2. маппер - возникла мысль писать дженерик-маппер, который будет знать, че откуда брать через аннотации в ДТОшке правда, тут все равно возникает вопрос - а откуда (уже ДТОшка) знает, как там в сущности все устроено?

2. маппер - возникла мысль писать дженерик-маппер, который будет знать, че откуда брать через аннотации в ДТОшке правда, тут все равно возникает вопрос - а откуда (уже ДТОшка) знает, как там в сущности все устроено?

вот потому пусть лучше маппер и знает как устроена ДТОшка и как устроена сущность

1. имхо вьюшки работают либо если у тебя круд + простые агрегации, либо если у тебя какой-нибудь es или подобное, где нужно проекции делать собирать в них какие-то сложные данные как по мне не айс

приведи пример сложных данных)

типа сумму посчитать?

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

приведи пример сложных данных)

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

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

ну вот я выше говорил - я для таких вещей все ж сущность буду спрашивать пока-что... хз как такое грамотно делать. Ну либо проекцию

ну как бы это решаемо

но блин, это как триггеры и хранимки - уносить половину БЛ в базу ой не хочется

ну как вариант - автоматизировать как-то... типа sql view as code, где на основании того, как сущность лезет в базу, соберется аналогичная вьюшка но это сложно и я не уверен в том, насколько это выгодно

но блин, это как триггеры и хранимки - уносить половину БЛ в базу ой не хочется

ну вьюшки это все ж не БЛ, как мне кажется

если ты начинаешь выносить в них логику, которую я описал - граница размывается

такое на sql писать больно, как мне кажется) независимо от того, где у тебя этот sql будет лежать

потому во вьюшку пихать как-то в голову не приходит

ну тут да) это так, немного забегая вперед

а вот через юнион сделать из двух абсолютно разных таблиц, одну, подходящую под условия задачи — почему бы нет)

ну как вариант - автоматизировать как-то... типа sql view as code, где на основании того, как сущность лезет в базу, соберется аналогичная вьюшка но это сложно и я не уверен в том, насколько это выгодно

смысл?)

я думал над таким вариантом если что

в итоге просто вьюшки прекрасно справляются

в большинстве случаев тебе просто надо вывести стэйт)

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

репорты ты ж на sql делаешь)

репорты ты ж на sql делаешь)

хехехе) на самом деле у меня репорты не особо репорты, так что проблем нет

хехехе) на самом деле у меня репорты не особо репорты, так что проблем нет

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

ты ж sql пойдешь писать)

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

причем в большинсте случаев мне даже вьюшки делать не надо)

ну вот смотри. ты достаешь из базы сущность, потом конвертишь ее в DTO, потом конвертишь ее в json

У меня в проекте нет DTO-шок вообще. В сабскрайберы если нада передать пишу метод $event->getEntity() если нужно в сервис пробросить инжекшу entity . Не вижу спислу конвертировать это в промежуточной DTO обект.

А если хочется spa потыкать, что из js ного нынче прям модно? React норм?

Не для проекта, а понимания процесса о_О

Не для проекта, а понимания процесса о_О

Angular/React/Vue.js - вроде эта аббревиатура у всех на слуху + на хабре с завидной частотой появляются статьи об их сравнительном анализе или миграции чела с одного фрейма на другой.

А если хочется spa потыкать, что из js ного нынче прям модно? React норм?

https://insights.stackoverflow.com/trends?tags=reactjs%2Cangular%2Cvue.js Самый простой способ измерения популярности

https://insights.stackoverflow.com/trends?tags=reactjs%2Cangular%2Cvue.js Самый простой способ измерения популярности

при этом реакт фактически более популярен но лично я пока что предпочитаю вью