self - ыуда ))))

весело живём🤡

Добрый день всем! Подскажите по архитектуре. По опыту, очень часто требуется добавить логику в модель, что бы вызывать ее напрямую во вьюхе/сериализаторе и тд. Но в саму модель передавать сервис нельзя(гайды симфони не рекомендуют, но и в принципе понятно почему, это же только модель).
Например, если сервис определяющий годность продукта от кучи параметров. Сейчас я в контроллере делаю $shelfLife = $service->getShelfLife($product) и передаю во вьюху. Точно так же вынужден писать еще в 3-4 контроллерах и сериализаторах, что мне не нравится, тк можно забыть, другой разработчик может не знать что это нужно, методов из сервиса может быть много и все это некрасиво передавать дальше отдельными переменными  и тд.
Как лучше в таких случаях делать? Может статью посоветуете хорошую на эту тему?

Есть такая штука, как DTO (Data Transfer Object). Заполняете её и передаете во все вьюхи

DTO это такой plain object. Заполняется чем угодно. Может иметь геттеры с логикой.

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

ну то есть вся разница в том, что в контроллер я пишу не $shelfLife = $service->getShelfLife($product), а $dtoEntity->setShelfLife($service->getShelfLife($product))

и точно так же, нужно вручную инициализировать во всех точках входах в приложения

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

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

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

Я пробовал делать DTO расширением класса модели, надеясь, что doctrine корректно подхватит аннотацию из базового класса, но возникают ошибки при гидратации и DTO остается пустой

Да, на основе данных в сущности и сервисов

У вас в сервисе хранятся данные?

нет, ну может пара констант

Нельзя прописать саму логику в сущности?

нет, мне кажется это плохая идея

Чем эта идея плохая?