[lsync]

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

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

Если определение этих наборов переложить на контроллер - он будет сильно разрастаться. Поэтому я и разделил на несколько контроллеров и назвал их сервисы.

1. Разрастаться будет ничуть не более, чем конфиг роутера.

2. Разделить на несколько контроллеров и назвать их сервисами - это супер, но то, что вы написали в первом посте, требует наличия внешнего роутера. Он ни к чему в данной цепочке - лучше сделать его внутренним. Причины:

• внешний роутер не имеет алгоритма формирования древовидных моделей;
• в случае запроса двух и более сервисов одновременно (а для формирования HTML-страниц всегда будет запрошен более чем один сервис) внешний роутер сделает два запроса к приложению. В худшем случае - это дважды и более "раскачать" тяжеловесный слой модели. Пример: на странице выводится список друзей пользователя и список его личных сообщений. Внешний роутер заставит модель дважды обратиться к БД за сущностью Пользователь. Конечно вы это можете кешировать (проблема есть - костыль готов), но можете просто положить в дерево ответа и не запрашивать повторно.
• снижается переносимость приложения в целом - добавляя новый сервис вам недостаточно задеплоить его в приложение, нужно ещё поменять конфиг роутера и перезапустить его. Моими сервисами я могу динамически управлять через веб, независимо от того, за кем они находятся.

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

Собственно, получается то, о чем я писал в первом посте.

Совпадение с тем, что вы писали в первом посте, только по пункту 4, в остальных разница, сильно влияющая на функциональность.