И к слову дело не в экономии строк, а в

DX.
Я хочу писать код, который делает задачу. Мне нужна сущность, я явно описал как его получить в аннотации и получил, зафигом мне тут зависимость от репозитория, который ещё тоже писать надо?
Если у меня конкретный класс обёрнут в крутые штуки, которые позволяют мне сущности получать аннотациями, логично что оно и транзакции сверху контролирует.

Итого я сосредоточен на задачах бизнеса, а не занимаюсь обмазыванием кода инфраструктурными флашами и явными транзакциями

вы в этом случае просто переносите код в аннотации, ничего более аналогично можно сваять $this->argumentResolver->getAnyEntityById(...) это опять же явное и неявное вам нравится чувство крутости и того что "это" понимаете вы и еще пару человек а мне нравится код код простой как двери, даже в ущерб крутости

Дело в уменьшении зависимостей. В моём примере у меня конструктора даже нет. Такой код в разы понятнее и легче тестируется. Крутость это не инженерный термин

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

Тесты так не пишутся. Если надо протестировать всю цепочку, так тестируй всю цепочку от реквеста до респонса. Пытаться воссоздать последовательность мидлварей в тестах это бред. Либо пишешь юнит тест на 1 хендлер без зависимостей, либо как в моём примере выше не пишешь, ибо он на столько простой, что стат анализа достаточно

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

А можно точнее? Вот есть soft code а есть hard code. Если ты стремишься к последниму, то твой код не гибкий и сложноподдерживаемый. И наоборот soft code силшком сильно прегружает логику абстракциями, мелко дробя логику на уровни. Аннотации это крутая вещь. Просто нужно помнить что аннотация в основном это замена конфигурации. Какая разница где её писать, в yaml или в самом коде. Я вот любитель ЯВНОГО кода. И эту явность я люблю проявлять в бизнес логике. Что там происходит в фреймворке - вообще плевать, главное чтоб бизнес логика была понятная и ЯВНАЯ. Да и подумай подругому. У тебя rest api. Каждый эндпоинт это ресурс. Вот пользак отсылает тебе запрос DELETE:users/123 - вот зачем тебе по 100 раз вручную брать репозитории, получать пользака по id (сам id ты должен получить из реквеста). Абстрагируйся - просто сразу получи пользака в эндпоинт и вызови у него $user->delete() а дальше если не было доменных исключений система сама сделает flush. Изи!

а в чем проблема тестировать код с аттрибутами? метод класса ожидает какую-то энтитю - создаём инстанс класса, даём ему эту энтитю и всё. аттрибуты в таком случае проигнорируются

ну раз вам так удобнее, я ж не против. я приверженец другого подхода

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

при создании сущности ты можешь пользоваться flush вручную если нужно вернуть id. или пользуйся готовыми крудами где ты просто настраиваешь энити а дальше всё работает