[x-yuri]

Наблюдая за другими проектами, мне понравился способ, при котором страница, на которую пришел запрос, сама вытягивает нужные ей данные.

за какими именно проектами?

Исходя из этого требования, становится понятно, что первый и третий варианты не подходят - придется дублировать агрегацию данных
для шаблонов и AJAX-запросов. В первом варианте шаблон сам агрегирует нужные ему данные. Во втором этим занимается отдельное приложение. А кто будет это делать для AJAX? Не круто.

неочевидно, приведи пример

1. Шаблон напрямую обращается к источникам данных (базе, например).
2. Шаблон дергает некую ручку (приложение), которое обращается к данным, формирует их в нужном формате и возвращает.
3. Приложение (а не шаблон), получает нужные данные из источников и передаёт их одной пачкой в шаблон.

т.е. твой объединенный объединенный вариант - 3-ий вариант, который в зависимости от шаблона "получает нужные данные из источников и передаёт их одной пачкой в шаблон"? Так это чистый 3-ий вариант, получаемые данные определяются шаблоном в любом случае.

Эмм, это уже лишнее. Всё-таки окружения разные, значит и код должен быть разным.

почему нет? Я слышал такой аргумент в пользу nodejs, собственно вот

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

очень смутно представляю, что и как будет разрастаться...

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

Если такая терминология подходит, предлагаю переходить на неё. Если нет - объясни какие моменты считаешь нелогичными/непонятными.

вы какую-то свою терминологию (а может и реализацию) придумываете, вас трудно понимать. Самый распространенный вариант - контоллеры и экшены. Экшены - действия, контроллеры - группы действий. И url часто имеет вид: /[controller[/action[/id]]], например /users/delete/1 или /users

Реализация у меня такова, кратко:
1. Шаблон, выступает в качестве client-side/virtual-client-side приложения, никак не связанного c View и ни с чем другим. Собственно он дергает ручки контролера.
2. Контролер, занимается перенаправлением требований от client-side и не более того, то-есть client-side дергает ручку контрола, контрол дергает нужную модель, на основе запроса.
3. модель, собственно занимается формированием данных, обработкой запросов и т.д. Формирует данные и отдает их уже выходному view.
4. View, собственно отвечает за то в каком виде отдать клиентской части данные, в формате JSON ( тоесть по запросу AJAX ) либо уже сформированное view представление.

Разница в веб приложениях лишь в том, что нет прямой связи клиентской части приложения с серверной. Тоесть клиент получает выдачу того что нарулил сервер, в чем огромное отличие например в обычных приложениях, где есть прямая связь View с контролером без посредников.

подожди, ты сравниваешь веб- и десктопные приложения? B~Vladi тебя не об этом спрашивал. И меня этот вопрос тоже интересует (в чем отличие твоей реализации?), потому что я не вкурил её, реализацию...

DjDiablo, я все еще помню, что ты обещал помочь с тестированием разобраться :\

p.s. карма напомнила ситуацию в Зимбабве