Maximizing.ASP.dot.NET.Real.World.ObjectOriented.Development [Electronic resources] نسخه متنی

History

One of the things that made the visual development environments so popular was the fact that they enabled you to drag and drop controls onto a form, and then the program would write code that would react to action on that control. For example, in a Visual Basic application, you could drag a button onto a form and then double-click that button in the development environment to create method code that would handle the clicking of that button.

This method of dealing with events on a form in a Windows application is, by comparison to a Web app, easy to implement. The application, at any given time, is in a known state in memory. The application knows what the mouse is doing, knows what's on the screen, can access resources such as the computer's hard drive, and so on.

You can understand, then, that trying to duplicate this type of event handling on the Web poses certain challenges. The Web, by its very nature, is stateless. A request comes to the server from a user's browser, and the server does some processing and then responds by sending HTML back to the browser. After the server has finished sending the response, it "forgets" about the request. It doesn't really know or care about the state of controls in the user's browser, and if there are 10,000 simultaneous users, it can't be bothered with all that data.

ASP.NET addresses the need to develop visually and simulate state on the stateless Web with some clever tricks that enable you to develop applications in a similar manner to a Windows application developer. The first part of this is the hidden __VIEWSTATE input tag in the rendered HTML of the form. Listing 7.1 shows a fairly large sample from a rendered page.

Listing 7.1. Viewstate rendered to the finished page

<input type="hidden" name="__VIEWSTATE"
 value="dDwtMTcwMzMxMDE2NDt0PDtsPGk8MT47aTwzPjs+O2w8dDxwPGw8aW5uZXJod
G1sOz47bDxDb2FzdGVyQnV6eiAtIEhvbWU7Pj47Oz47dDw7bDxpPDU+Oz47bDx0PDtsPGk8MD4
7PjtsPHQ8O2w8aTwxPjs+O2w8dDw7bDxpPDI+Oz47bDx0PHA8cDxsPFZpc2libGU7PjtsPG88Z
j47Pj47Pjs7Pjs+Pjs+Pjs+Pjs+Pjs+PjtsPF9jdGwwOl9jdGwwOlNpdGVSZXBlYXRlcjpfY3RsMDpf
Y3RsMDtfY3RsMDpfY3RsMDpTaXRlUmVwZWF0ZXI6X2N0bDI6X2N0bDA7X2N0bDA6X2N0bDA
6U2l0ZVJlcGVhdGVyOl9jdGw0Ol9jdGwwO19jdGwwOl9jdGwwOlNpdGVSZXBlYXRlcjpfY3RsNjpf
Y3RsMDtfY3RsMDpfY3RsM
DpTaXRlUmVwZWF0ZXI6X2N0bDg6X2N0bDA7X2N0bDA6X2N0bDA6U2l0ZVJlcGVhdGVyOl9jd
GwxMDpfY3RsMDtfY3RsMDpfY3RsMDpTaXRlUmVwZWF0ZXI6X2N0bDEyOl9jdGwwO19jdGwwO
l9jdGwwOlNpdGVSZXBlYXRlcjpfY3RsMTQ6X2N0bDA7X2N0bDA6X2N0bDA6U2l0ZVJlcGVhdGVyOl9
jdGwxNjpfY3RsMDtfY3RsMDpfY3RsMDpTaXRlUmVwZWF0ZXI6X2N0bDE4Ol
9jdGwwOz4+BW1dvuXwoUhYlCbVaKY2H4hNGgg="
 />

The viewstate is an encoded representation of the state of the controls on the page. It lets the server "remember" what it sent to the browser. For example, it might indicate that a drop-down has certain values and a certain item selected, or it might contain the entire contents of data in a DataGrid.

All this information hidden in the HTML does come at a price. Each time the page is loaded, or a request is received from the same page, that data has to be encoded and/or decoded. Multiply that by thousands of users, and you can see where this process might become a problem. We'll look at the implication of this in Chapter 15, "Performance, Scalability, and Metrics."

The other part of this simulated form state is of course postback. ASP.NET's postback mechanism causes the entire contents of a page's form to be "posted back" to the server for processing. These form element values, combined with the information in the viewstate, can be compared so that changes can be sensed and some kind of processing can take place.

You might compare this arrangement to a traditional Windows application. In Windows, when an event is triggered, the application checks the state of things in memory and does something. In the ASP.NET application, the browser posts back to the server, the old and new form states are compared, and the server sends back HTML to reflect the changes.

The truth is, as a developer, you probably don't really need to know what's going on in the background during this process. In fact, many people might find it easier that way. For example, say you have a button on your form. When the user clicks the button, it fires off an event handler on the server that you wrote, which in turn saves some data to a database. You could just as easily leave it at that and not be concerned with the fact that a postback occurs. That's a leap of faith for developers who come from script backgrounds because you have to trust that all of the plumbing provided by ASP.NET works correctly.

However, after you're comfortable with this postback model, it's helpful to know what's going on because it can help you diagnose performance problems later on.