Действительно ли Asp.net MVC устраняет viewstate?

Question

Одной из основных проблем с веб-формами ASP.net является механизм viewstate, который занимает много полосы пропускания, потому что он сериализует все входные данные формы и отправляет их по командам post.

В книге, которую я читаю, упоминается, что одним из главных достоинств MVC над веб-формами является то, что mvc не содержит viewstate. Звучит довольно круто, но из того, что я вижу, mvc также отправляет все входные данные для команд post (это единственный способ, которым он может использовать свой механизм привязки).

так в чем же разница? вы можете назвать его состоянием просмотра, вы можете назвать его «привязкой», но нижняя строка и MVC, и веб-форм сериализует все входные данные и отправляет их все на POST.

Я не прав? если нет, то в чем разница?

Answer 1

Большая разница. Viewstate может стать довольно большим. Он сохраняет значения, которые не обязательно содержатся в данных формы. Подумайте о GridViews, Label и т. Д. Они не находятся в полях ввода, но сохраняются через ViewState. В MVC действительно нет понятия постоянства. Вы можете вернуть данные в представление (хотя механизм привязки делает это довольно простым)

Answer 2

В WebForms вы имеете дело с System.Web.UI.WebControls, и все элементы управления должны хранить некоторые данные внутри viewstate

, но в MVC вы имеете дело с нативным протоколом html и http.там вам не нужно представление состояния.

смотрите вступительное видео для ASP.NET MVC:

http://www.asp.net/mvc/videos/5-minute-introduction-to-aspnet-mvc

Answer 3

ViewState отличается от общего вида POST.Когда вы выполняете POST, вы, очевидно, должны включить все входные данные, иначе сервер не сможет обработать данные.

ViewState хранит другие свойства элементов управления, такие как цвета, привязка данных, текстовые значения.и т. д. Эти значения отправляются в браузер и обратно, чтобы сохранить состояние каждого элемента управления на странице, но они не являются частью «данных», обрабатываемых сервером при публикации.

Answer 4

Я не буду повторять то, что говорили другие, но добавлю, что WebForms - это фреймворк для использования псевдосохраняющей парадигмы. Подобно настольным приложениям, у которых есть состояние, WebForms является хорошим примером для передачи части этого состояния в унаследованную без сохранения состояния сеть. Основным механизмом достижения этого является ViewState. ViewState - это не только сериализованное содержимое текущего элемента управления, но также может использоваться для сериализации и поддержания состояния моделей. Это то, что дает WebForms свою полноту состояния.

MVC, с другой стороны, возвращается к традициям более классической структуры без сохранения состояния, и поэтому не нуждается в ViewState. Я не согласен с тем, что привязка модели такая же, как и ViewState, поскольку привязка модели не учитывает какое-либо предыдущее состояние (если вы вручную не восстановили состояние модели из кэша сеанса / приложения и т. Д.), Модели создаются управляемыми в рамках срок действия запроса только. тогда как в модели WebForms вы могли бы сериализовать ваши модели, чтобы придать состоянию вашего приложения.

Answer 5

Как именно вы намереваетесь обрабатывать любые данные формы, не передавая значения обратно на сервер? Это глупый аргумент. Да, Posting действительно передает значения формы на сервер, потому что это единственный способ, которым сервер может их обработать.

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

Это совершенно другая вещь.

Answer 6

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