I’m departing from my normal show a lot of code methods here, to talk about an idea.
ASP.NET MVC denegrates ASP.NET Web Form’s old state-maintenance construct called Viewstate. Without Viewstate, many developers are wondering how — more aptly where — to preserve the state of a web-application. Here I will be explaining my favored answer — serializing your model to JSON — and showing why.
SOME HISTORY
In ASP.NET Web Forms, page state was stored within a highly compressed, encrypted hidden form field. This allowed .NET web developers to persist the state of the GUI controls with little-to-no effort. Unfortunately, AJAX came along. AJAX developers found ASP.NET Web Forms didn’t play nicely at all; and that since Viewstate was encoded, AJAX developers couldn’t easily work-around ASP.NET Web Forms limitations.
ASP.NET MVC
The Model-View-Controller architectural pattern could easily be called the state/GUI/event-handler pattern. Personally, I feel that most ASP.NET MVC examples nail showing off the Controller, and by proxy do a pretty alright job showing off the View. But simple examples often have simple domain logic, and hence the Model and state-maintenance has been largely ignored. This is important to note, because HTTP is a stateless protocol, yet the MVC pattern was designed for persistantly stated desktop applications.
“The model manages the behavior and data of the application domain, responds to requests for information about its state (usually from the view), and responds to instructions to change state (usually from the controller).” – Steve Burbeck, from the paper first describing MVC
STATE MAINTANENCE IN MVC
Given the statesless nature of HTTP, most ASP.NET MVC examples imply that the Model is little more than a “page model” with some supporting domain logic. For the Model to act across multiple pages, we must persist that model between page requests… and we have options… databases, mutiple hidden form fields, sessions, cookies, etc..
The common denominator is that each page request must somehow reconnect to its Model. In many cases, the Model — or at least the current pertinant chunk of the Model — is small enough to reasonably be persisted with each page, much as Viewstate was. The huge advantage to custom Model persistance comes in saving the Model to a hidden-form-field in the form of Javascript Object Notation, or JSON. Using JSON means that not only will the Model be persisted, it will also be available for AJAX developers to update without full-page-postback.
ISN’T PUTTING THE MODEL IN THE VIEW BAD?
Considering the alternatives, no. Sure, persisting the Model to a database would have some security benefits — at the expense of connection overhead. Sessions or cookies work as well — with their own known limitations. You could also — God forbid — break your model into little bits and persist each one as necessary. Let me say this is the WORST possible thing you could do, because it requires the View to know the entire Model to do its job. The code to serialize to JSON is the same for any object you throw at it, and changes to the Model won’t have to be duplicated in each View.
CONCLUSION
Of course, there are limitations to persisting your Model via JSON. HTTP Get/Post have character limitations you must consider. You will want to validate your model on each page post. Overall, however, the benefit to AJAX developers outweighs the security awareness necessary to implement this state-management architecture, and prevents your ASP.MVC architectures from falling into the rut of “page-state”.
