index0h

Объект Request по хорошему стоит воспринимать как иммутабельный и вообще не производить с ним ни каких изменений. Установка кук - это задача Response. Жабы отдельно, гадюки отдельно.

Попробуйте уменьшить выборки и вставки, по чаще вызывайте очистку энтити менеджера, где это уместно. Запускайте сборщик мусора

Контроль доступа - по возможности выноси в контроллер, с помощью Voters например.
Валидацию данных - рекомендую выполнять в каждом публичном и защищенном методе. Да, это вроде как гемор, но такой подход экономит время коллосально на отладке. Непосредственно в Entity валидация в сеттерах.
https://github.com/index0h/php-conventions

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

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

ctrl+c -> ctrl+v

Зря я написал EntityDtoLoader?

Кто знает, вероятно зря.

Или как лучше?

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

Есть еще вариант - под каждый экшн сделать отдельный класс *Form / *Message, который на вход получает Request, прям в конструкторе вытягивает данные, валидирует их и запихивает к себе в приватные свойства, преобразовав типы. Наружу предоставляются геттеры.

https://github.com/index0h/php-conventions

https://www.doctrine-project.org/projects/doctrine...

Самый плоный api symfony - это и есть symfony

Контроллер в шаблонизаторе... звучит как треш.
Запилите сервис для вашего entity и уже его дергайте - да, по говну но быстро. По хорошему для шаблонизаторна следует подготавливать все данные заранее.

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

Проверьте, включен ли debug режим, очень похоже на то. Для инсертов я бы на вашем месте транзакцию заюзал на пачки в 1к например. 5кк раз пересчитывать индексы - это очень печально. Если категорий у вас не много - имеет смысл их затащить в память все, а дергать мускуль лишний раз не стоит. Смысла в detach при clear / close нет, от слова совсем.

Юзайте интерфейс Collection + docblock.

/**
 * @return Point[]|Collection
 */
public function getPoints(): Collection;

@Route("/products/{limit}/{offset}", name="products"), а дальше вытягиваете limit/offset из $request->attributes

Если сервис 1 и сервис 2 должны юзаться еще где-то, имеет смысл вынести их функциональность либо полностью отдельно, без транзакций, либо частично в публичный метод. В 3-ем юзать одну транзакцию.

Если так не делать - работа с событиями после flush, и ему подобными становится как минимум сложной.