| The biggest difference between Windows Forms controls and Web Forms controls is that while the Web Forms control is visibly displayed on the user's screen, no instance of the control exists on the server. This seems to be a difficult concept for many programmers to grasp. It is not a new concept either, because it was just as true with ASP. It makes sense when you understand that all server-side scripts or compiled programs only execute for brief moments at a time. Usually it is the amount of time between a request and a response. This is very different from Windows programs which execute for as long as the user wants, until they close the program. Why am I going into this in a discussion of Web forms data binding? Because in order to understand data binding you have to understand the life cycle of the controls (see Figure 9.1). The controls actually only exist for very brief periods of time between requests and responses. This is why there are no events in Web controls like keystroke or mouse events. They have no where to go! Figure 9.1. Web Form life cycle.  Requests and Responses The concept that you have to grasp about web-based applications is that they consist of a series of requests and responses. It really isn't an event-driven model the way Windows is. A request comes from the user and goes to the server. The response is what the server sends back to the user. Requests can have the form of the user entering a URL is the address box, clicking a link, or posting a form by clicking the Submit button. The response is usually HTML but it can also be a command like a redirect. It's interesting but this is really not much different from the old CICS and COBOL on IBM mainframes. Basically, the user filled out the screen and then submitted it to the queue, where a COBOL program was waiting to process the input. Once processed , the COBOL program would then send another screen back to the terminal. The more things change, the more they remain the same, right?  | 
