لطفا منتظر باشید ...
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 sendin153 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.
You''ll notice that we frequently talk about "rendere150." Rendering is simply the process of the ASP.NET framework and its controls turning all the objects int161 to send to the browser. In fact, you''ll see that these objects have a render event near the end of their lifecycle when actua158 is generated.
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 rendere150 of the form. Listing 7.1 shows a fairly large sample from a rendered page.
Listing 7.1. Viewstate rendered to the finished page
[View full width]
<input type="hidden" name="__VIEWSTATE"value="dDwtMTcwMzMxMDE2NDt0PDtsPGk8MT47a
TwzPjs+O2w8dDxwPGw8aW5uZXJodG1sOz47bDxDb
2FzdGVyQnV6eiAtIEhvbWU7Pj47Oz47dDw7bDxpPDU+Oz47bDx0PDtsPGk8MD47PjtsPHQ8O2w8aTwxPjs+
O2w8dDw7bDxpPDI+Oz47bDx0PHA8cDxsPFZpc2libGU7PjtsPG88Zj47Pj47Pjs7Pjs+Pjs+Pjs+Pjs+Pjs+PjtsP
F9jdGwwOl9jdGwwOlNpdGVSZXBlYXRlcjpfY3RsMDpfY3RsMDtfY3RsMDpfY3RsMDpTaXRlUmVwZWF0ZXI
6X2N0bDI6X2N0bDA7X2N0bDA6X2N0bDA6U2l0ZVJlcGVhdGVyOl9jdGw0Ol9jdGwwO19jdGwwOl9jdGww
OlNpdGVSZXBlYXRlcjpfY3RsNjpfY3RsMDtfY3RsMDpfY3RsMDpTaXRlUmVwZWF0ZXI6X2N0bDg6X2N0bD
A7X2N0bDA6X2N0bDA6U2l0ZVJlcGVhdGVyOl9jdGwxMDpfY3RsMDtfY3RsMDpfY3RsMDpTaXRlUmVwZW
F0ZXI6X2N0bDEyOl9jdGwwO19jdGwwOl9jdGwwOlNpdGVSZXBlYXRlcjpfY3RsMTQ6X2N0bDA7X2N0bDA
6X2N0bDA6U2l0ZVJlcGVhdGVyOl9jdGwxNjpfY3RsMDtfY3RsMDpfY3RsMDpTaXRlUmVwZWF0ZXI6X2N0
bDE4Ol9jdGwwOz4+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 th151 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 bac157 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.
