Introduction: 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
- 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.
- 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.
- 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?
- 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.
- 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="" />
- _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;
theform.submit();
}
// -->
</script>
- ASP.NET generates _doPostBack() automatically.
- Code inside this function grows, as more AutoPostBack controls are added to the page.
- Control whose AutoPostBack property is true is attached with _doPostBack() method by onClick or onChange property.
- 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','')"
language="javascript">
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.
Benefits:
- Server resources are freed after each request.
- More scalable.
Limitations:
- Because view state is stored in the page, it results in a larger total page size.
- ASP.NET uses view state only with page and control properties.
- View state isn't a good place to store sensitive information that the client shouldn't be allowed to see.
Okay so it's some action time, we will do an exercise to actually see how ASP.NET serializes and de-serializes page view state and how it is stored in hidden input fields.
Step 1: create a ASP.NET application
Step 2: Add a label and button
<div>
<asp:Label ID="Label1" runat="server" Text="Label"></asp:Label>
<br />
<asp:Button ID="Button1" OnClick="Button1_Click" runat="server" Text="Button" />
</div>
Step 3: Write handler for Button1_Click.
protected void Button1_Click(object sender, EventArgs e)
{
//retrieve the view state string for the current web page using server-side
string viewStateString = Request["__VIEWSTATE"];
// viewStateString contains the view state information.
// Convert the Base64 string to an ordinary array of bytes
// representing ASCII characters.
byte[] stringBytes = Convert.FromBase64String(viewStateString);
// Deserialize and display the string.
string decodedViewState = System.Text.Encoding.ASCII.GetString(stringBytes);
Label1.Text = decodedViewState;
}
![aspdotnetVS.gif]()
The view state string isn't human readable — it just looks like a series of random characters.
When you look at the decoded view state string, you'll see something like this:
? -162691655dd-Text Hello, worldddd????4 ?????U?Xz?
Note: You can notice that the value is quite visible in this random generated string, so it's not advisable to store sensitive data in view state.
What is View State Chunking?
Scenario: When the page size exceeds a specified limit, many firewalls and proxy servers won't allow the pages to pass. To overcome such a problem, we have a technique called View State Chunking, which automatically divides view state into multiple fields to ensure that no hidden field exceeds a size threshold you set.
How to activate View State Chunking: We need to add a few lines of code in web.config file for the system.web element.
<configuration>
<system.web>
<pages maxPageStateFieldLength = "1024" />
</system.web>
</configuration>
So when we request a page that generates a view state size larger than this value, several hidden input fields will be created.
I hope you enjoyed this ride.
Cheers!