MVC. А нужны ли Контроллеры?

Мне концепция MVC в принципе, достаточно нравится, но в мелочах сильно раздражает. У нас есть бесправные View, которые по факту про всё знают и активно занимаются навигацей. У нас есть тупые Модели, которые периодически берут на себя заботу о данных, и есть Контроллеры, занимающиеся непонятно чем, только не тем, чем нужно.
MVC позволяет писать гибко, но за эту гибкость приходится расплачиваться жёсткими гайдлайнами или же полной неразберихой. Кто должен готовить данные для View? Контроллер, Модель, внешний слой бизнес-логики? И если внешний слой, то он должен возвращать Модель, или модель должна его использовать для наполнения, или контроллер должен заполнить модель, имеющимися данными?
Модель должна быть ViewModel или настоящая, живая? А может быть просто DTO?

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

Все контроллеры в приложении примерно равны

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

Контроллеры разделены логически, а не функционально

Вот смотрите, есть у нас класс User и какой-нибудь UserManager, который отвечает за создание пользователей, получение данных, редактирование и удаление. Всё просто и логично. Теперь делаем приложение, контроллеры и получаем UserRegistrationController, UserProfileController, UserAdministrationController и использование пользователей в каких-нибудь RoleManagerController, GroupManagerContoller, LoginController и куче других. Можно пытаться сделать один большой контроллер, но получим помойку, т.к. функционал администратора управляющего пользователями сильно отличается от функционала нового, регистрирующегося пользователя. В результате, с одной стороны мы раскидываем работу с пользователями по куче контроллеров, с другой, при попытке их объединить мы получаем жуткую чехарду с функционалом и контекстом.

Контроллеры занимаются самыми разными вещами

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

Вот такая вот подлость с этими контроллерами. А как решать эту проблему — я не знаю. У меня не настолько светлый ум.  Но если хотите моего мнения (а если не хотите, то всё равно напишу): утащить всю логику в некое WebAPI со своей маршрутизацией. Это WebAPI будет заниматься получением и сохранением данных, не трогая контроллеры. А за самими контроллерами оставить простейшую логику по отдаче нужных страничек по урлу, максимально вырезав из них всё остальное. И идти дальше, разбираться с View и Models.