Does Asp.net MVC really eliminates viewstate?
One of the main problems with ASP.net webforms is the viewstate mechanism, which takes a lot of bandwith because he serializes all the form inputs and sends it on post commands.
In the book i'm reading it's mentioned that one of the main virtuous of MVC over webforms is that mvc does not contain viewstate. It's sound p开发者_开发技巧retty cool but from what i'm seeing, mvc also sends all the inputs on post commands (this is the only way he can use his binding mechanism).
so what is the difference ? you can call it view state , you can call it "binding" , but bottom line both MVC and webforms serialize all the inputs and sends them all on POST.
Am i wrong ? if not, what is the difference ?
Big difference. Viewstate can get quite large. It retains values which are not necessarily contained in form data. Think of GridViews and Label's etc. They aren't in input fields yet they get persisted through ViewState. In MVC there really is no concept of persistence. It's up to you to return the data to the view (although the binding mechanism makes this fairly easy to do)
ViewState is different from a general form POST. When you POST you obviously have to include all of the inputs, otherwise there is no way for the data to be processed by the server.
ViewState stores other properties about controls, such as colors, data binding, text values, etc. These values are sent to the browser and back again so that the state of each control on the page is maintained, but they are not part of the "data" being processed by the server when posting.
In WebForms you are dealing with System.Web.UI.WebControls and all of the controls need to store some data inside viewstate
but in MVC, you are dealing with native html and http protocol. you do not need viewstate there.
watch the intro video for ASP.NET MVC :
http://www.asp.net/mvc/videos/5-minute-introduction-to-aspnet-mvc
How exactly do you intend to process any kind of form data without passing the values back to the server? That's kind of a silly argument. Yes, Posting does pass the form values to the server, because that's the only way a server can process them.
Viewstate is a dictionary that contains state data for every control on your page, that is passed via post data. MVC doesn't have viewstate, so there is only the current contents of form data when a post occurs. There is no page state, only session state (which is stored on the server).
It's a totally different thing.
I won't recycle what others have said, but I will add that WebForms is a framework for using a pseudo-stateful paradigm. Much like desktop applications which have state, WebForms is good example at bringing some of that statefulness to the inheritly stateless web. The primary mechanism by which it achieves this is ViewState. ViewState is more than just the serialised content of the current control, but can also be used to serialise and maintain the state of models too. This is what gives WebForms its statefulness.
MVC on the other hand returns to the traditions of a more classical stateless framework, and as such has no need for ViewState. I wouldn't agree that Model Binding is the same as ViewState, because Model Binding doesn't respect any previous state (unless you manually restored the state of a model from session/application cache, etc.), models are created managed within the lifetime of the request only. whereas in the WebForms model, you could serialise your models to give your application state.
In my opinion mvc doens't eliminate it. There is still a need to keep data from other post in wizard pages' type. Here is link how to do it in a view state way! Of course someone can argue that you can keep that data manually in hidden fields but it require a lot of work and doesn't prevent from data tampering.
The short answer is YES, Asp.net MVC eliminated viewstate and handles state with different mechanisms.
精彩评论