Проблемы понимания MVC в ASP.NET MVC и не только

Случайно ответил в основную ветку

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

Строго говоря асинхронный метод это когда сервер получает запрос и какой нибудь колбеск а потом по своей инициативе вызывает клиента чтобы отдать ему данные.

Нет, к сетевому уровню асинхронность отношения не имеет. Один и тот же запрос клиент может считать синхронным, а сервер асинхронным — на уровне сети синхронность и асинхронность пропадают.

А почему вы считаете, что это определение применимо к asp.net MVC, хотя документация и литература (ну вот например Эспозитовский Programming Microsoft ASP.NET MVC) говорят об обратном? Вот одна цитата:

In general, there are at least two distinct models—the domain model and the view model. The former describes the data you work with in the middle tier and is expected to provide a faithful representation of the domain entities. [...] The view model just describes the data being worked on in the presentation. [...] two distinct models logically exist, and coexist, in a typical layered web solution. You might decide that for your own purposes the two models nearly coincide, but you should always recognize the existence of two distinct models that operate in two distinct layers.

Если опираться на это описание, то предлагаемое вами решение для структурирования всех трех компонентов становится полностью неприемлемым.

Я не говорю, заметьте, что это решение неприемлемо вообще. Я говорю всего лишь, что asp.net MVC построен на другой модели, и пытаться навязать ему вашу будет болезненно.

М — полнофункциональная модель предметной области. Не имеет связи ни с контроллером, ни с представлением.

V — средство отображения, кроме шаблонов обладающее собственной логикой

C — набор действий — конечных точек маршрутизации.

Если оно такое естественное то откуда все это бесконечные дискуссии (включая эту) о том как должны взаимодействовать компоненты

Во многом — из непонимания, какой же именно паттерн используется. Еще — из-за эволюции паттерна со временем. Дело, однако в том, что эти дискуссии возникают не только для серверной имплементации паттерна (т.е., того, что вы назваете "вебом"), но и для клиентской, а это как раз изначальное его (паттерна) место.

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

у MVC нет проблем, проблема часто в понимании того что MVC это паттерн для уровня пердставления, а не для всего приложения.

а model2, это грубо говоря адаптация mvc для веб приложений

В какой то мере я согласен. Да, часто для сайтов SPA не подходит, особенно возникают проблемы с поисковиками.

Но все же это не попытка изобразить на клиенте подобие десктопного приложения.
Часто это нужно для элементов интерфейса которым критична перезагрузка страницы. Допустим для формы ввода комментария который я сейчас набирал.

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

и как же выглядит «что именно отрендерить

Архитектурным паттернам вообще свойственно быть размытыми. Иначе бы разработка архитектуры ПО уже давно была простой и понятной дисциплиной.

Именно об этом я и писал, я так понимаю что он живет в слое presentation, а собой представляет фасад над уровнем бизнес логики… по этому в нем легко менять поведение при сбоях и т.д. не совсем понимаю где я сделал ошибку в своем утверждении.