Надеюсь, что тухлыми помидорками новичка не закидают. Только осваиваю симфонию,

есть задача при сохранении изображения из формы его сразу ужать как мне надо. Оказалось, что все это, а заодно и кэширование превьюшек (что тоже нужно) умеет liipimagine
И тут встает вопрос по архитектуре уже самой симфонии. Для того, чтобы сохранить файл из разных форм мне кажется логичным написать код где-то отдельно. Это правильнее делать в контроллере специально обученном? Или для таких целей есть какие-то другие подходы? Просто в моем понимании, контроллер в первую очередь отвечает на запросы, может я туплю, конечно.

контроллер контролирует. Грубо говоря смысл контроллера в том что бы сконвертить http запрос в действие приложения. Контроллеры не должны прнимать решений сами (делигируют кому-то, например какой denyAccessUnlessGranted). Есть так же argument value resolvers которые позволяют какие-то общие вещи по работе с данными запросов выносить выше. Удобно для мэппинга структур каких и т.д. В случае кто должен непосредственно загрузку делать - сервисы. Контроллер опять же ленивый менеджер и все делегировать должен.

я тоже только осваиваю, для понимания работы можно и в контроллере оставить, но потом это вырастет в толстый контроллер вот другой подход ImageUploader https://github.com/adelf/acwa_book_ru/blob/master/manuscript/1-bad-habits.md

Ну, вот Сергей, ИМХО, пишет верно. Контроллер для другого. Пойду читать про сервисы и работу с ними. Тут еще непочатый край работы. А за ссылочку спасибо, поизучаю тоже.

Контроллеры, которые просто перекладывают запросы в сервисы в симфе нафик не нужны. Тут достаточно мощный фронтконтроллер, который позволяет обращаться напрямик к сервисам. Роутинг + аргумент резолвер и вуаля, половина гетовых контроллеров превращается в метод репы. Остальное в другие сервисы. А контроллеры как точки входа становятся просто бесполезными

Я именно это и говорю. Но логики в контроллерах быть не должно. Не потому что "контроллер" а потому что много зависимостей. Логика должна быть там где зависимости минимизированы (whole value это ещё называется)

Ну я веду к тому, что мы называем "контроллерами" должнф быть как раз конечные сервисы (даже не сервисы, а функции - метод сервиса это прото частный случай). Которые могут быть вызваны по запросу, по событию, из консольной команды. Да вообще пофик откуда - это самостоятельная штука. А вот разруливание всяких внешних условий, таких как проверка прав, маппинг реквеста на ДТОшку, валидация и другие общие для всех реквестов и не относящиеся напрямик к выполняемому действию штуки, должны разруливатся уровнем выше в одном единственном на весь проект фронтконтроллере, который в симфе находится в HttpKernel е Ну это в идеале конечно.

Это просто миграция названий... Вы делаете одно и другое и суммарно получается то, что и делаете... с др названиями Теперь хэндлер называется контроллером, и из cli команды вы его дёргать собираетесь... что сейчас люди и делают с хэндлером. Контроллер теперь что-то другое, по факту тоже самое, с др названием... Не совсем понятно зачем минрировать термины и все делать как было, ну видимо вам виднее

Это отказ от "контроллеров" как просто передастов запросов в хендлеры.

Откажетесь, но на фронт-контроллере все равно абстракцию наворачивать... как не назвать, но реквест для роута надо переварить

Чет фигня тогда получится. Один большой класс с кучей аннотаций

Эээ, нет, не правильно вы меня поняли

Только это не отменяет того факта что контроллер эти проверки должен делегировать кому-то.