Looking deep inside PostBack and ViewState in ASP.NET 3.5


ASP.NET helps in rapid development of web forms in a way similar to our Windows counterpart writes code to develop Windows application for the desktop. Development is rapid in a Windows application for many reasons, i.e. there is no page life cycle etc.

Major Difference between Window Application and ASP.NET

  1. Web applications are executed on the server, while Windows applications are executed at client side. In a web application, users see web forms in a browser and provide inputs, which is posted back to server. ASP.NET handles this GAP between browser and server by a technique called PostBack, which send the page and all other user information to the server when certain action is performed.
  2. ASP.NET used HTTP wire which is Stateless: for every round trip, and before the HTML output is rendered, all the user information and web page controls objects are destroyed. Although this is good to avoid heavy traffic application, but its challenging to maintain a seamless experience to user. So to maintain persistence state, ASP.NET uses a technique called ViewState.
  3. Event Model: Windows programmers have an upper edge when it comes to programming a rich event model, say programming for mouse click, key presses, or any other low level control interaction. But when it comes to ASP.NET, client actions happen at the client side and server processing takes place at server. This means there is certain amount of overhead involved in responding to events in ASP.NET.
ASP.NET Control Automatic PostBack: 

Description: The only option to send a page, both for HTML and ASP.NET is by clicking a submit button. Although when a page is posted, ASP.NET fires another event. This model is extended in ASP.NET control with an Automatic Postback Feature. I.e. input control can fire different triggers and server side code can handle it immediately.

How it works: ASP.NET controls have property AutoPostBack. If set to True, ASP.NET uses client side abilities of javascript to bridge the gap between client-side and server side. It is set to False by default. So if we want optimum performance by not causing a change event.

What ASP.NET does?
  1. ASP.NET adds a javascript function to the rendered HTML page, "_doPostBack ()". When called, it triggers a postback, which is posting the page back to the server with all information.
  2. ASP.NET adds two hidden input fields that the _doPostBack() function uses to pass information back to the server. One is ID of the control that raises the event and second is any other information.

    <input type="hidden" name="__EVENTTARGET" id="__EVENTTARGET" value="" />
    <input type="hidden" name="__EVENTARGUMENT" id="__EVENTARGUMENT" value="" />
  3. _doPostBack() sets these values with the appropriate information about the event and then submitting the form.

    <script language="text/javascript">
    function __doPostBack(eventTarget, eventArgument) {
    var theForm = document.form1;
    theform.__EVENTTARGET.value = eventTarget;
    theform.__EVENTARGUMENT.value = eventArgument;
    // -->
  4. ASP.NET generates _doPostBack() automatically.
  5. Code inside this function grows, as more AutoPostBack controls are added to the page.
  6. Control whose AutoPostBack property is true is attached with _doPostBack() method by onClick or onChange property.
  7. ASP.NET automatically changes a client-side JavaScript event into a server-side ASP.NET event, using the __doPostBack() function as an intermediary.
Real Example: 

Say we have a List control whose AutoPostBack property is set to True. So it posts back automatically whenever the user changes the selection in the list, the client side onChange fires up. The browser then calls _doPostBack() which sends the page back to the server.

<select id="lstCountry" onchange="__doPostBack('lstCountry','')"

ASP.NET ViewState:

How ASP.NET page model works: Each time the page is posted back, it loses control object information and other user information. As changes are done in the page by the user, the page is changed from its initial state. Traditionally, statelessness has been overcome with the use of simple cookies, session-based cookies, and various other workarounds.

What is View State: It is ASP.NET integrated state serialization mechanism to keep state of page controls in postback.

How it works: Just before page code has finished running and HTML has been rendered to send back to the client, ASP.NET examines all the properties of the controls and if any property has been changed from its initial value , ASP.NET make note of it in name/value collection like Hashtable. Then ASP.NET takes these values and serializes into Base64 String. Final string is inserted in the <form> section of page as new hidden field.

  1. Server resources are freed after each request.
  2. More scalable.
  1. Because view state is stored in the page, it results in a larger total page size.
  2. ASP.NET uses view state only with page and control properties.
  3. View state isn't a good place to store sensitive information that the client shouldn't be allowed to see.