сущность не должна этим заниматься

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

Тогда контроллеры будут ужасные

Смысла не будет вообще юзать сущность. т.к. я буду создавать обьект а потом в репозитории его из обьекта в массив обратно

Но как без сущности то

А создавать подобие сервиса под это вообще тупо

Есть норм вариант?

Почему у тебя конструктор возвращает сериалайзер?

да - создаешь сервис-фабрику и юзаешь :)

А нет.

Сори.

да - создаешь сервис-фабрику и юзаешь :)

А маппер тогда куда?

В сущности?

Массив маппера

Массив можно в сущности

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

ок. Тогда куда маппер?

в репозиторий можешь заинжектить как вариант

А в сервис засунуть почему нет?

Дк прикинь будет много сущностей

сериалайзер и есть сервис

Че это все в сервисе хранить

Сервис можно инжектить в сервис

Сервис долен выполнять работу простую.

Тогда два абстрактных сервиса. Один в обьект, другой из обьекта с возможностью маппера. Маппер в репозитории. Норм?

Дк прикинь будет много сущностей

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

ну и плюс тебе весь этот код копипастой носить по всем типам обьектов

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

ну и плюс тебе весь этот код копипастой носить по всем типам обьектов

Ну это можно вынести в родительский класс. Так что это не проблема. Но да, я согласен что такое в сущности делать не надо

Вообще для юзер сущности нет проблемы имплементить Serializable

Но репозиторий работает с сущностью. Передавать туда массив тупо

там никого это не смущает :)

serializable это уж совсем для других целей

Ну а тут в чем проблема?

Ну типы разные.

Но суть-то та же :)

в serializable обьект должен уметь уснуть и проснуться

а конвертировать себя в array, json, xml, yaml это ему нахер не нужно

А тут должен превратиться в массив и из него в объект

этим занимаются нормализаторы и гидраторы

Ну Трансформер может тогда сделать?

этим занимаются нормализаторы и гидраторы

Один хрен у симфони это все один компонент

Но репозиторий работает с сущностью. Передавать туда массив тупо

у тебя есть метод findById(), ты делаешь там запрос, тебе вернули массив и на выходе делаешь return $this->normalizer->denormalize($data, User::class); а методе save наоборот. save(User $user), там делаешь normalize и сохраняешь это как массив в базу

Один хрен у симфони это все один компонент

интерфейсы разные, а гидраторы это вообще не часть симфони. это доктрина

findById возвращает обьект

да, для того кто вызвал его

а внутри у тебя там мясорубка

Где вообще симфони юзает нормалайз и денормалайз? А то нет под рукой проекта

для сериализации обьектов в json в основном

normalize это промежуточное состояние между обьектом и json

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

не абстрагированно.

Она гидрирует данные в сущность согласно аннотациям

Ну либо другому конфигу

Ну это понятно. Но где она это делает? На каком этапе?

Стектрейс посмотри. Я не интересовался. :)

Мне нужно щя понять делать сервисы или родительские классы для сущности и репозитория

Там где hydrate происходит

Лучше оставить энтити плейн объектами

И создать например сервис-трансформер.

В нем преобразовывать туда обратно

Ну это понятно. Но где она это делает? На каком этапе?

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

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

с блекджеком

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

Он должен быть только файндером, так сказать :)

ему не нужна лишняя абстракция

ERROR: S client not available

Сделай трейт :)

Круто говоришь. Вот только я без доктрины

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

в чем проблема взять доктрину то?

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

тяжелая кудах ко-ко

Никто не даст разрешение

Давно бы уже сделал

т.е в конструктор запихнуть инициализацию сериалайзера это норм, а взять доктрину, которая оптимизирована это не норм

Это лишь один из вариантов

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

Сейчас норм но противоречит логике

К тому же юзается не симфони а сайлекс

Максимум что я могу пропихнуть это доктрин дбал абстракцию

Но она тут не особо спасет

Каждый разговор с тимлидом о доктрине закачивается тем что она весит АЖ 10 МЕГАБАЙТ

боже

Омг

Приглашаем его в чатик

ну, это можно понять, если он место на сервере экономит, например

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

Не, тут база на 100гб

никакая она не жирная

Врятли он экономит

это сказки

ДК я знаю

Его то я не смогу переубедить

Тут огромный проект на велосипедах и чистых запросах к базе

Нет бы доктрину подрубить и для новых задач юзать ее

Но нет. Давайте будем писать свою доктрину несколько лет

...