Just read blog post of Maarten Balliauw.
Wanted to ask will
<%Html.Serialize("person", Model); %>
return bunch of 'don`t-stop-debugging-heavily-server-sided' RAD controls?
Is that's a good idea to include this?
If so - what kind of usage would be appropriate?
I view it more as a way of avoiding using the session to transfer data between actions than viewstate per se, and that's what I would use it for. Seems to me an ideal way to implement some wizard type functionality in which you want to carry the data forward through a series of actions before you persist anything to the database. There is, of course, the danger of overusing it I suppose, but as long as the framework doesn't automatically impose it on you, then I don't see the same dangers of viewstate popping up. With viewstate, you had to jump through hoops (and potentially break other things in the process) to avoid it.
We shouldn equate Base64 encoding with ViewState. I don't see the state of the view being serialized in that snippet. I see the state of the model. So describing that as ViewState For Asp.net MVC is very misleading.
Also consider this is opt-in and not automatic in any way. It's primary usage will probably be for optimistic concurrency as well as Wizard UIs where you want to store the users previous selections in the view as opposed to the Session or Cookie.