Не могу ничего сказать против, но есть пара уточняющих моментов:
sf2 это HTTP Request-Response фреймворк, а ещё MVCS (аля Grails) по идеологии бизнес-логика должна быть в сервисах, а контроллеры/экшены должны её вызывать. Так и тестировать легче возможно.
Когда-то даже себе сделал такое Controllers Pray
Take request
~~~~~~~~~
Create form
Bind form
~~~~~~~~~
Call one service method
Send response
сеция ~~~ необязательная
Action очень жестко завязан на Request
да, но логика — нет, ибо она находится в сервисах. Прекрасно использую логику из сервисов когда нет никакого реквеста, пример: CLI команды.
Как вириант:
1.1 глобальные переменные вынести в конфиг
1.2 из конфига при его загрузке переложить эти переменные в DI контейнер
1.3 сделать twig-helper который будет легко вызывать из любого места любого шаблона, а уже хелпер будет будет узнавать/уточнять эти параметры у DI контейнера
Вариант попроще: захардкодить Ваши глобальные переменные в twig-helper`е — это самое простое.
>>2. работать с Request и Response итд.
Если Вам нужно работать/изменять Request/Response где-либо помимо самого контроллера (и сервисов которые он вызывает) то тут Вам помогут Listener`ы
1. нужно ли приводить пример конфига, его разбора и реализации twig-helper?
2. нужно ли приводить пример работы с Listener`ами?
Не могу ничего сказать против, но есть пара уточняющих моментов:
sf2 это HTTP Request-Response фреймворк, а ещё MVCS (аля Grails) по идеологии бизнес-логика должна быть в сервисах, а контроллеры/экшены должны её вызывать. Так и тестировать
легчевозможно.Когда-то даже себе сделал такое
Controllers Pray
сеция ~~~ необязательная
да, но логика — нет, ибо она находится в сервисах. Прекрасно использую логику из сервисов когда нет никакого реквеста, пример: CLI команды.
Окей, а что есть тогда симфонийские роли?
PS
прошу помнить — я не холиварю.