wittyrider

или внедрят по тайп хинтингу

На самом деле тут есть варианты:
- написать compile pass который будет агрегировать всю эту инфу + param converter который будет инджектить сервисы в контроллер (можно взять за основу готовые штуки, типа как тут и тут
- использовать PHP-DI

Остается вариант контроллеры как сервисы.

Этот вариант хорош только в случае если у нас контроллеры толстые, что само по себе плохо.

Как у вас организованно контроллеры?

экшен контроллера собирает данные из запроса (можно просто кастомные запросы делать и через парам конвертеры разруливать) и передает в сервис уровня приложения, потом выводит результат его работы. Использую get метод и не парюсь, контроллеры это вообще не то о чем надо париться (кроме того что они должны быть тонкими).

ИМХО, сейчас нет ничего лучше симфони 2. Чем больше ей пользуюсь, тем больше она мне нравится.

Удобная модульная архитектура, сервисы, отличная документация. В ней из коробки есть twig, который очень удобен(я не любитель нативных шаблонов). Doctrine 2 - лучшая ORM из тех, что я пробовал(тоже из коробки). Конфиг в yml и аннотациях - тоже не малый плюс(по сравнению с зендовскими массивами читаемость выше на порядок). Куча сторонних бандлов практически на все случаи жизни. Удобная админка от сонаты(правда документация её так себе, и на освоение может ни одна неделя уйти).

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

Бандлы - самодостаточные модули инкапсулирующие какие-то сервисы и прочую штуку. По сути это расширения для DependencyInjection, если очень грубо.

Модели - это те самые Entity грубо-говоря. Вообще есть такое понятие как Доменная-модель. Это просто структура данных, сущности которыми оперирует бизнес логика. Последняя должна быть инкапсулирована в сервисы (всякие UserManager, PostManager и т.д.). В Yii модели смешаны с сервисным слоем и по этому у вас получается путаница.

Что до кода... есть распространенный подход иметь свой AppBundle и фигачить все в нем. Есть так же рекомендуемый подход - не использовать бандлы вообще. То есть.... бандлы должны быть самодостаточны и их основное предназначение - реюз логики между проектами. Бизнес-логику приложения реюзать у вас не выйдет, поэтому рекомендуется просто писать код и регистрировать его в app/Resources/config/services.yml или что-то в этом духе, как именно решать вам. Профит в том что вы на замарачиваетесь всей этой фигней с бандлами и у вас возникает меньше вопросов по структуре. А если же вы захотели что-то вынести в бандл - например сервисы для авторизации которые реально можно реюзать, то вам никто не помешает это сделать. В итоге у вас будет структура проекта приблизительно такая:

| - app
| - var
| - src
  | - Controller
  | - Entity
  | - Bundle/
    | - MyAuthBundle/
| - web

ну как-то так. Как не странно такой подход не сильно распространен в Symfony-сообществе хотя его рекомендуют в недавно вышедшем бест практис буке и в принципе эта струтктура более чем логична.

Что до виджетов, в Symfony2 есть HMVC. То есть вы можете сделать эдакие под-запросы на другие контроллеры внутри вьюшек. Можно скажем все "виджеты" инкапсулировать как отдельный контроллер с методами и дергать их из вьюшек.

<div id="sidebar">
    {{ render(controller('AcmeArticleBundle:Article:recentArticles', {
        'max': 3
    })) }}
</div>

Это дает больше гибкости, внутри каждого контроллера можно дергать другие контроллеры. Можно прикрутить кеширование на уровне обработки запросов (кешировать скажем все подзапросы по каким-то критериям) и т.д.