Asp.net

After working with ASP.Net for over a year, and participating in the Microsoft ASP.Net newsgroups for quite awhile, I have observed that many people who are new to ASP.Net are having some fundamental difficulties understanding how it actually works. This is particularly important with ASP.Net, much more so than with ASP. Why? Because ASP has a fairly straightforward approach to creating dynamic content, and is procedural. ASP.Net is object-oriented, and has a number of features built in which seem to confuse people. For example, with ASP it was fairly obvious to most of us that there is an impenetrable gulf between the server and client, because HTTP is stateless, meaning that the browser and server only respond to individual page requests, and do not maintain any kind of state between requests. But Microsoft did some fancy tap-dancing, and came up with an event-driven object model which seems to eliminate this gulf, when, in fact, it does not. It simply works around the gulf. For some, understanding object-oriented programming concepts has turned out to be very difficult. However, as Internet programming becomes more and more powerful, the organization that object-oriented programming affords will prove out. For those of you unfamiliar with object-oriented programming, check out my ASP Programming Fundamentals article.
The purpose of this article is to give a little look "under the hood" of ASP.Net, to familiarize you with the similarities and differences between ASP.Net and ASP. You may be surprised to discover that the 2 technologies are not really that much different. If you are unfamiliar with the fundamentals of ASP, you should read the beginning ASP tutorials on this web site first, as this article will not reiterate those points, but will focus instead on the similarities and differences between ASP and ASP.Net. We will begin, however, with a review of the underlying technology, including the basics of HTTP Thin-client Applications.
HTTP Thin-client Applications: HTTP is a protocol for transferring data between a web server and an HTTP client application. The most commonly-used HTTP client application is a Web Browser. A Web Browser is a "thin client" meaning that it contains virtually no code for doing much of anything but making requests to a server, executing certain kinds of code, such as JavaScript, in an HTML page, and displaying HTML documents. The concept of a thin-client application is that the server does all of the processing work, and delivers content in the form of HTML to the client, which simply renders the HTML output from the server. The client browser can have HTML elements in it for uploading data with its request to the server, such as Forms, Query Strings, and Cookies. But, other than some client-side JavaScript (or Java Applets, ActiveX Controls, SWFs, etc.), the browser does very little processing.
HTTP State Considerations: HTTP is stateless, meaning that when the browser makes a request for a page, script, or whatever, it retains no knowledge of the currently loaded document, nor does the server. Each document is loaded into memory by itself as it is received from the server, and unloaded with the next request. The server, likewise, keeps no record of the past requests, but receives each request as if it were brand new. This means that maintaining state (persisting data between page requests) is a problem. A number of workarounds have been developed over the years, for the purpose of emulating state between requests. These include Cookies, passing data in Query String parameters, Form post data, and the concept of Sessions. Sessions are a bit different, however, as they reside on the server. A Cookie is created on the client with the Session ID, to maintain the Session ID from one request to the next, and the actual Session data is stored on the server. However, note that each of these solutions doesn't actually bridge the client-server gap, but emulates a bridge, by passing data back and forth between the client and server. This is possibly the most important concept that you can grasp here, as much of what follows is built on this foundation.