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

помню что это плохо, но не знаю почему. хотел узнать

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

Контейнер нужен, когда у тебя есть циклические зависимости: class ServiceA { public function __construct(ServiceB $serviceB) {} } class ServiceB { public function __construct(ServiceA $serviceA) {} } вот так ты сделать не можешь но можешь прокинуть в ServiceB контейнер и оттуда дергать ServiceA это уже неправильно, не должно быть такого рефакторишь так, чтобы сервисы не вызывали друг друга либо переносишь связанное в какой-нить сервис, чтобы друг друга не дергали либо выносишь в отдельный сервис и уже его инъектишь либо у тебя код общий, но делает разное и тебе не надо этот код шарить (он будет в каждом сервисе, но в данном случае это не плохо)

так любой сервис зависит от контейнера в каком то смысле

с помощью сеттеров можно сделать цикличскикую связь) Иногда это полезно.

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

привет) а кто в курсе насколько сильно забивает память если, допустим, я использую 3 сервиса, и в каждом в конструктор пихаю контейнер? насколько помню во второй это новый инстанс, хз как в 5й

для работы сервиса контейнер не нужен контейнер нужен для создания/получения сервиса но при этом сервисы создавать можно и без контейнера, напрямую контейнер просто упрощает работу почитай про di, service locator, etc, может понятнее станет

посмотри sf serializer,там это используется

Причем тут сериалайзер и контейнер, вы же не сериализуете сервисы.

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

Так и как циклические связи сервисов используются в сериалайзере?

В нормлазерах очевидно же

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

Ну посмотри как он под капотом устроен и все поймешь) Времени объяснять точно нету.

Ну посмотри как он под капотом устроен и все поймешь) Времени объяснять точно нету.

Но иногда без этого никак

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

Нормалайзеры не являются сервисами, на сколько я помню.

Как вы пришли к этому выводу?

Понаставят сералайзеров. Лишь бы Джейсон сериалазбл не имплементировать

debug:container

Если у объекта суть - отразить данные из базы и уехать на фронт, то он сам должен это реализовывать.

Поясните пожалуйста примером

Звучит не очень просто, пахнет CQRS и вызывает много вопросов )

Стараюсь обходить стороной такие сложности, потом не найдешь никого на поддержку. Если предметная область требует ддд, или нагрзуки требуют cqrs то выбор пхп на мой взгляд сомнителен.