тоесть тебе надо мэпить на сущности

объекты могут быть вложенными

symfony/serializer?)

тоесть тебе надо мэпить на сущности

в большинстве случаев да

а что он умеет?

он умеет то же что jms serializer но нормально

читаю

если структура json не меняется сильно, например меняются только названия полей, то можно просто из коробки юзать

иначе нужно будет свои нормалайзеры/денормалайзеры писать

у меня api уже сформирован

я не могу его менять

ну так я и не передлагаю

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

но ты всегда можешь написать свой денормалайзер

то есть довольно гибкая штука

понял

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

а мне не нравятся императивные мэпперы

хочу декларативненько

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

а как ты сейчас мэпишь?

руками в сеттеры?

да

прям в контроллере

у моих сущностей нет сеттеров

из джейсона вытаскиваю, в сеттер сую

а зачем тебе тогда доктрина?)

ну мол какой профит от анемичных моделек?

у меня и доктрины нет

а что есть?

набор мапперов, которые напрямую с DBAL Connection работают

ааа

ну "мапперов"

ну тогда норм

хз тогда

у меня чуть более конкретная штука

у них даже общего интерфеса толком нет

мэппинг данных на запросы

мои модели больше напоминают DTO

там логики нет

кроме валидации

понял, тупо гейтвей к базе данных

ну да

я бы firebase взял и не писал бы бэкэнд)

для КРУДа наверно так и надо было поступить

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

очень любопытно

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

че столько слоев?

не много

просто это не совсем уж CRUD

просто такая схема развязывает руки

хочешь дергай действия из CLI-ных команх

хочешь, из обработчиков очередей

хочешь - из других хэндлеров, че нет

надо сделать пакетную обработку - не вопрос, дергаем хэндлер в цикле

а read model - просто отдельшая шляпа которая формирует ответы

это из нововведений на моих проектах... раньше была боль из "замэпить сущность на массивчики и выплюнуть в виде json)

front controller это какой-то middleware в твоем случае?

тип того

в симфони - http kernel и ивент листенеры

ага

тупо прячут рутину вроде "сделай респонс"

или "замэпь реквест"

в обратную сторону у меня похоже

контроллер возвращает массив, который потом превращается в json вне контроллера

ERROR: S client not available

я понял

у меня попроще и погрязнее

ну для CRUD подобное лепить смысла не особо много

а RegisterUserRequest это наследник HttpRequest?

или не обязательно

нет, просто final класс

я стараюсь не юзать наследование

от слова совсем

у меня частями похоже

авторизация, например. слушает определенные параметры запроса и создает объект User, если может

User приходит в контроллер как простой параметр из запроса

ээээм

авторизация? аутентификация?

что на вход приходит?

аутентификация, да

токен какой-нибудь?

да

токен в заголовке

у меня для аутентификации надо просто проверить подпись

JWT и все такое

далее можно создать класс UserSession

и впихнуть туда пэйлоад токена

и уже через него рулить авторизацией. Юзера же из базы доставать не надо.

а как инвалидировать jwt?

никак

потому время жизни токена ограничено

на одном из проектов было жесткое требование "дропать сессии"

в итоге я в jwt дописывал id сесии

и если такой небыло валидной - дропал

но это можно на мидлвэрю повесить

а сессии в redis держать.

в итоге я в jwt дописывал id сесии

ну и какой тогда смысл в jwt?