Пожалуй спрошу
fastcgi_split_path_info ^(.+\.php)(/.+)$;
Оно в 2021 нужно?

Я не знаю(

Ну если у тебя этот другой Entity есть, значит пофиг откуда ты получаешь данные, это полюбому relation.

Читай доку по доктрине, от корки до корки. Такие вопросы должны отсреливать сами. Пока сам не поймёшь, ничего толкового с таких советов не будет.
Ну то есть тебе насоветуют и скорее всего правильно, но толку если ты через час уже забудешь.
А вот если сам поймёшь как это работает, то будешь это знать и через год.

Согласен. Просто не всегда сразу доходит, прочитав из доки. Когда ручками пару раз делаешь, не получается, ищешь причины - и потом доходит.
Сейчас уже код работает. Всё норм. Сел рефакторить. Переношу методы из контроллера в нужные места. Надо понимать куда они должны быть перенесены.И сейчас доку листаю...

Ну значит ты не понимаешь азов.

Что вобще за метод create()? Откуда это? Это какая-то лично твоя кастомщина. У меня в проекте никаких create() методов нет. И думаю у большинства симвониводов тоже.

Я создаю сущности конструктором, в простых случаях. Или фабрикой для дурацкой бизнесс логики .

Думаю в твоём случае лучше не рефакторить, а написать всё заново, следуя всем рекомендациям документации. ))

А в чем проблема большого кол-ва проперти и сетеров у ентити, если того требует логика приложения?

Если сложная логика, то ее нужно декомпозировать, и инкапсулировать. Одна ентити должна решать какую то конкретную задачу, а не много разных. Врядли какая то логика завязна на 30-50 свойств.  Хотя если логика не инкапсулирована в сущностях, то уже наверное пофиг, ведь это просто прокладка между базой и логикой.  Проблема лишь, то тащить много лишнего будете, если не использовать партишл, что уже является не очень практикой (как мне помнится из доки доктрины)

П.С. Под логикой подразумевается какие либо дейсвтия, а не просто хранение = логика приложения

Когда совсем разные данные в одной ентити то это плохо. Бывает и 50+ свойств, например описание человека

"Описание" врядли имеет логику

Только если из этих 50+ свойств есть хотя бы одно, значение которого повторяются у кучи записей, то уже есть смысл подумать о декомпозиции. Но только подумать )))

Пихать все данные пользователя в одну сущность это плохой подход просто

Почему?

Потому что получается сущность на 50 полей, сценарии использования которых не пересекаются

фесора на тебя нет))

Например есть UserProfile где есть рост,вес, цвет глаз и т.д. Какой смысл такие данные разделять на несколько сущностей?

Если это вычленено из User - это норм

Но если там есть логика больше чем просто хранение, то стоит задуматься о декомпозиции

Нету, а вот вынести его логины/пароли и данные для связи, например, есть смысл частенько

Там изначально кто-то говорил что 30+ сетеров это плохо. Вот и возник вопрос почему человек так думает. Если данные неотделимы друг от друга то хоть 255 если того требует логика