1

I've been learning about MVC for a while, and I think I pretty much understand what it's all about. But there is one thing I don't yet understand: I keep hearing with MVC that there is no viewstate nor postback.

Can someone explain what this means in simple terms?

alex
  • 6,818
  • 9
  • 52
  • 103
GordonHowe
  • 11
  • 1
  • 3

2 Answers2

3

Try this SO answer which addresses the same question.

Extra info after comment/question:

ASP.Net web forms can use viewstate to store the state of server controls on the page and to manage invocation of server side events such as a button click. The idea is to present a programming model that is similar to the Win Forms approach to make it easier for Win Forms developers to transition and knock out browser based apps. To learn about it in depth you should hit google and learn about the asp.net page life cycle which will explain the overall process and explains where viewstate processing fits in. Here's a pretty good explanation.

ASP.Net MVC is a different programming model that uses different view engines to generate your markup - i.e. the content that actually streams back to your browser client. To an extent it removes a lot of the "magic" that web forms introduced but in return you can produce more standard markup and have greater control over what will be rendered to the client. If you're learning MVC take a look at the NerdDinner sample chapter which is a good tutorial as well as the MVC Music Store. Throughout those are good intros to doing MVC.

MVC doesn't use/need viewstate or postbacks as it's a different programming model. Which is better/more appropriate for any given project is a big debate that I'll let others have as I think both have their strengths and can be useful in different scenarios (although I personally mainly use MVC now...). You're right that things are done differently... you can't just work with the simple event driven approach that web forms imitates but then MVC has lots of strengths of its own which you'll find across countless blog posts comparing webforms vs MVC.

Community
  • 1
  • 1
Chris W
  • 3,304
  • 3
  • 26
  • 28
  • Thanks for the link. I checked it out but I'm still very confused. It seems the poster who is posting on that link already knows what view state is. What I don't understand is how ASP.NET needs view state and ASP MVC doesn't. Does that mean there are things I cannot do in ASP MVC or are things just done differently? – GordonHowe Dec 30 '10 at 10:40
  • if the "viewstate" data is not appearing in mvc , it will jhave to be saved elsewhere and i guess it is a server. but then youll have to manage/remember each "state" for a user and I assume youll do it in cache. so will you generate a token for each user ? can you elaborate ? – Royi Namir May 22 '13 at 13:43
  • @Chris W can you please answer my question ? – Royi Namir May 22 '13 at 14:55
  • @RoyiNamir "viewstate" is not something that you use in MVC - it doesn't need to be saved elsewhere, it simply doesn't exist. You may be confusing ViewState and Session state so I'd recommend you read up on the two to understand how they differ. Session state is still available for you to use on the server in your MVC application - or you could use some other kind of cache if you wish using a key of your choosing to tie entries to a particular user but the most appropriate choice will very much depend on your application's requirements. – Chris W May 24 '13 at 15:04
  • no im not confusint them :-). I just ask where would you save state changes for a UI , if there is no login. you must track that user somehow.... where would you save its ui changes ? session ? – Royi Namir May 24 '13 at 15:08
  • Sorry to give a vague answer but the "correct" approach would very much depends on your particular scenario. You'd typically maintain state with a blend of querystrings, well crafted routes/URLS & form POST values. The POST values may be hidden inputs which to an extent could be seen as rolling your own basic version of what viewstate did. On the server side you might also be storing some user context data in Session or, as your suggested earlier, in a cache with a key generated in part from the username or some other identifier. – Chris W May 24 '13 at 15:56
0

MVC Do not have viewstate and session but you can use TempData Object instead of viewstate. in your controller you can bind like this TempDate["MyKey"]="My Value" and in the next request you can get your value in action like String s=TempData["MyKey"]

Mohsen Rahimi
  • 21
  • 4