4

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 pretty 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 ?

tereško
  • 58,060
  • 25
  • 98
  • 150
OopsUser
  • 4,642
  • 7
  • 46
  • 71
  • 3
    It's not required for ViewState to be send out with each request. You can modify the Page Persister to store the ViewState in say, the session if bandwidth is a problem. I think the bigger issue with ViewState is it gives the developer the incorrect idea, that they are programming a stateful app in an inherently stateless environment. – Xhalent May 19 '11 at 21:49

7 Answers7

4

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)

ek_ny
  • 10,153
  • 6
  • 47
  • 60
  • you can disable viewstate in controls where you dont need and it wont serialize so much data, in fact you can disable viewstate for entire pages. and enable it only in the controls that need it like textboxes. – Luis Valencia Oct 08 '11 at 20:08
2

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.

mellamokb
  • 56,094
  • 12
  • 110
  • 136
  • 1
    What if I have a button and a label, and when I press the button , I set the label value to "lala". now the form do submit. When the page returns , how will the mvc will remember that the label had the value "lala" ? and how will i solve it with MVC ? – Royi Namir Apr 30 '13 at 16:22
2

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

tugberk
  • 57,477
  • 67
  • 243
  • 335
1

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.

Erik Funkenbusch
  • 92,674
  • 28
  • 195
  • 291
  • What if I have a button and a label, and when I press the button , I set the label value to "lala". now the form do submit. When the page returns , how will the mvc will remember that the label had the value "lala" ? and how will i solve it with MVC ? – Royi Namir Apr 30 '13 at 17:31
  • @RoyiNamir - There are many ways to solve this, and how you would do it depends on your application. There are simply too many variables to suggest an appropriate solution. – Erik Funkenbusch Apr 30 '13 at 18:21
  • Ok... Can you please suggest your chosen solution ? How would you remember the label value ? (and the other 20 controls state ) ? – Royi Namir Apr 30 '13 at 19:06
  • @RoyiNamir - you have to get out of the "control" mindframe. They're not controls! The view is merely a rendering of your model. If you want to show diffent data, you post back to the controller and have your model render different data. – Erik Funkenbusch Apr 30 '13 at 19:47
  • I'll rephrase. I have span a and a button. when postback , how would the MVC will remember that the span had a value ? – Royi Namir May 01 '13 at 04:53
  • @RoyiNamir - It can't. Seriously, it's not supposed to. MVC uses the HTTP model, that means only things that are in form fields are submitted. If you want to change this, you need to figure out a way to do it yourself using your architecture. Use a hidden field, or post it as ajax so that when you refresh the page your controller remembers it and changes the render. I can't suggest how I would do it because I would never do it the way you want to do it. – Erik Funkenbusch May 01 '13 at 14:42
1

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.

Matthew Abbott
  • 60,571
  • 9
  • 104
  • 129
0

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.

Community
  • 1
  • 1
jan salawa
  • 1,198
  • 1
  • 8
  • 25
0

The short answer is YES, Asp.net MVC eliminated viewstate and handles state with different mechanisms.