Я думаю, что это имеет много общего с моделью postback + viewstate + events.
Вышеупомянутое происходит неявно, чтобы имитировать модель, в которой пользователь взаимодействует с приложением многоэтапным способом, где существуют различные состояния системы. Поскольку каждый элемент управления содержит свой viewState, каждый из них вносит свой вклад в это общее состояние, которое может стать трудно следовать по мере того, как страница растет по сложности. Я также считаю, что удобство поощряет указанную сложность.
Вышеупомянутый может быть скорее аргументом в пользу покоя, который способствует тому, чтобы больше полагаться на способ ведения протокола. Использование сообщений для достижения вышеуказанного, действительно не предусмотрено протоколом HTTP. Просто возьмите оригинальный встроенный пейджинг сетей asp.net, так как он был основан на обратных почтовых серверах, которые игнорировали все, кроме страницы 1. Также у вас больше не было доступа к указанной странице информации только по URL-адресу.
imho шаблон MVC в контексте asp.net MVC больше связан с простыми операциями запроса/ответа. Вы можете заставить его быть настолько сложным, насколько вам может понадобиться, но это способствует более простым операциям в том, чтобы делать что-то. Он не основан на работе с состоянием, основанном на нескольких разных битах информации, разбросанных по странице/представлению, как в классическом; но если это то, что вам нужно, вы все равно можете достичь этого, но при этом вы должны быть гораздо более явными.
ИМХО, что вы описываете, является отсутствие контроля без контроля и простоты управления сервером, я не вижу, как это противоречит MVC. –
@Oren рассмотрите MVP (презентатор представления модели) в микс. Одним из важных различий между этим и MVC является обработка состояния, поскольку MVP работает с представлением, которое изменяется на основе действий пользователя/поэтому независимо от того, где вы помещаете состояние, представление не является тем, что показано только один раз. В MVC вы показываете другое представление для каждого действия (да, вы можете показывать один и тот же файл/представление, но концептуально), следующее действие обрабатывается не связанным с предыдущим. С помощью asp.net classic + серверных элементов управления, что-то общее, показывает то же самое, но в этом элементе управления показывают эти данные/или скрывают это. – eglasius
Обратите внимание, что @tvanfosson может иметь что-то в виду относительно обязанностей взглядов и обязанностей диспетчера, поэтому у него может быть более прямое объяснение, основанное на том, что (а не) должно быть на представлениях. Для меня я нахожу это более ясным с MVP-сравнением, так как у вас может быть хорошо структурированное классическое приложение asp.net с ним, но все же показывает важную разницу с MVC. Я думаю, что способ MVC более согласован с природой HTTP. пс. обратите внимание, что asp.net MVC использует вариацию MVC, есть и другие варианты. – eglasius