Does Asp.net MVC Really Eliminate Viewstate?

Question

One of the main problems with ASP.net web formats is the submission mechanism, which requires a lot of bandwidth because it serializes all form inputs and sends them by message.

In the book I am reading, it was mentioned that one of the main virtuous MVC over webforms is that mvc does not contain a viewstate. This sounds pretty cool, but from what I see, mvc also sends all inputs to post commands (this is the only way it can use its binding mechanism).

so what's the difference? you can call this view state, you can call it “binding”, but in the bottom line MVC and webforms serialize all the inputs and send them all to POST.

Am I mistaken? if not, what is the difference?

Answer 1

Big difference. Viewstate can get pretty big. It saves values ​​that are not necessarily contained in the form data. Think of GridViews and Label etc. They are not included in the input fields, but they are saved through the ViewState. There really is no concept of perseverance in MVC. You need to return the data to the view (although the binding mechanism makes this pretty easy)

Answer 2

ViewState is different from the general form of POST. When you are POST, you obviously must include all the inputs, otherwise there is no way the server processes the data.

ViewState stores other properties of controls, such as colors, data binding, text values, etc. These values ​​are sent to and from the browser to maintain the state of each control on the page, but they are not part of the "data" processed by the server upon publication.

Answer 3

In WebForms, you are dealing with System.Web.UI.WebControls, and all controls must store some data inside the viewstate

but in MVC you are dealing with your own html and http protocol. You do not need a viewstate.

Watch the video for ASP.NET MVC:

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

Answer 4

How exactly are you going to process any form data without passing values ​​back to the server? Such a stupid argument. Yes, posting passes form values ​​to the server, because this is the only way the server can process them.

Viewstate is a dictionary that contains status data for each control on your page that is passed through the message data. MVC does not have a viewstate, so there is only the current content of the form data when a message occurs. There is no page state, only session state (which is stored on the server).

This is a completely different thing.

Answer 5

I will not recycle what others have said, but I will add that WebForms is the basis for using a pseudo-stateful paradigm. Like desktop applications that have state, WebForms is a good example of casting some of these states to a stateless inherited website. The main mechanism by which he achieves this is ViewState. ViewState is more than just the serialized content of the current control, but it can also be used to serialize and maintain the state of models. This is what gives WebForms its state.

MVC, on the other hand, is returning to the traditions of a more classical stateless structure and, as such, does not need a ViewState. I would not agree that the model binding is the same as the ViewState, because the model binding is not related to the previous state (if you did not manually restore the model state from the session / application cache, etc.), Models are created managed in Within the service life of the request. whereas in a WebForms model, you can serialize your models to provide your application state.

Answer 6

In my opinion, mvc will not fix it. It is still necessary to store data from another message in the page type of the wizard. Here is a link on how to do this in view mode! Of course, someone may argue that you can store this data manually in hidden fields, but this requires a lot of work and does not prevent data falsification.