Introduction: It is 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.
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 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 Microsoft 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.
Now, while state can't be maintained on the client side, it can be maintained on the server side, via a couple of possible alternatives:
Data passed back from client browser is passed back to client browser.
Data can be stored in memory on the server: Application State, Session State, other Cache objects, database, file system
Note that so far, we are talking about both ASP and ASP.Net, as the environment hasn't changed; only the programming model. This is very important to keep in mind!
How ASP Maintains State: One of the biggest differences between ASP and ASP.Net is that in order to do something as simple as maintaining the selected index of a drop-down list box ("select" object), you had to cook up your own code to do it. What you would do is to use the Request Collection to get the selected item from the drop-down list box, and write ASP/HTML code that wrote "selected" as an attribute of the appropriate drop-down list box in your HTML. See the following code illustration:
As you can see, this is fairly straight-forward, but if you have a lot of state to maintain, it can get quite verbose.
How ASP.Net Maintains State: When Microsoft developed ASP.Net, they analyzed the various types of common functionality which ASP programmers have had to incorporate into their applications, and developed the ASP.Net object model around this. Because ASP.Net is object-oriented and event-driven, classes were developed which would handle this sort of thing automatically. For this reason, and several others we will explore later, Microsoft developed Web Controls and HTML Controls. We will see that all of the differences in the programming interface add up to the same basic operation as ASP for maintaining state.
ASP.Net adds a hidden form field to a WebForm, called "__VIEWSTATE". This form field corresponds to a server-side object called ViewState. The ViewState object is a Collection of values from the form, which includes the values of all Web Controls and HTML Controls which have been set to maintain their state1 between PostBacks (a "PostBack" is simply the posting of the WebForm back to itself).
How ViewState Works: Here's how it's done. When the WebForm's HTML output is streamed to the browser, the hidden "__VIEWSTATE" field is added to the form. When the form is posted back to the server, the Request.Form Collection (same as ASP) contains the values of the posted form. The Server Control reads the form POST data, extracts the values, and updates (rewrites) the ViewState value to be sent back to the client. At the same time, the Server Control adds the appropriate HTML to the HTML object text to "set" it in it's proper (remembered) state, that is, the state the form field was in when the form was posted. In essence, ASP.Net is doing the same thing that ASP does, although you don't have to write all that code to make it so.
ASP.Net and Events: Another new feature of ASP.Net is Events. Events have been around for quite awhile in terms of object-oriented programming, but as ASP was not object-oriented, this was not available. An Event is a message, of sorts. Basically, what happens is this: When something happens, whether it is something a User has done through an interface, or something internal to a program's logic, the object which hosted the action sends a message to the Operating System. This message is in the form of an Event object, which contains certain data about the object which spawned the Event. Any object which hosts an Event Handler Method for that object's Event will be notified of the Event by the Operating System, and the Event Handler method is fired when the Event is "raised."
Of course, this brings up the question: How can an event which occurs in a client-side browser, which is disconnected from the server, be recognized by the server, and handled appropriately by both the server and the browser? And of course, the answer is obvious: An event is a message. The browser sends a "message" to the server with each Request. The Event can be communicated to the server in the Request. And the server can then render the appropriate HTML back to the browser according to the Event Handler, thus having the browser "react" to the event as well.
In fact, this is exactly what Microsoft designed into ASP.Net. When you create a WebForm page with Server Controls in it, ASP.Net adds several other hidden form fields to the page, as well as JavaScript "onclick" (for the most part - a select object, for example, has an "onchange" event handler added to it)) event handlers which call a JavaScript function called "__doPostBack()"2. The form fields are called "__EVENTTARGET" and "__EVENTARGUMENT". The following code was copied from the HTML of an ASPX page
When you add a server-side event to a Server Control or HTML Control, for example, an "onclick" event to a button, ASP.Net automatically adds a client-side "onclick" event handler to the HTML for the object2. The event handler calls the __doPostBack() method, passing the id of the control which fired the event in the "__EVENTTARGET" field, along with any special "__EVENTARGUMENT" data that may be needed on the server side. Note that the __doPostBack() method submits the form back to the server, creating a Request which contains the event data in the hidden form fields.
When the server-side Page class receives the Request, it sees the data in those hidden form fields, and reacts accordingly, raising a real (server-side) Event, which can then be handled by the Event Handler method you have developed (if any).
ASP.Net Controls: We have been using the word "control" fairly frequently here, and now would be a good time to explain the concept of ASP.Net Controls. In the Common Language Runtime (CLR), all classes of objects which are used in ASP.Net interfaces (the HTML document rendered) are derived from System.Web.UI.Control in some form or fashion. The origin of this term can probably be traced back to Windows Forms. All interface elements in a Windows Form are called Controls. The idea of ASP.Net Controls is basically the same: A Control is a class which has back-end processing, and renders a User Interface. In Windows Forms, the interface and back-end are in the same memory space, part of the same Application. In ASP.Net, Controls have back-end processing, and render an HTML interface in the Page. The main difference is that the HTML interface is separated from the back-end processing by the client-server "gulf".
Even the ASP.Net Page class inherits System.Web.UI.Control, just as a Windows Form inherits from Control. A Page has back-end processing and renders an interface in the browser. Like any other Control, it has a Controls Collection. It has the same sequence of Events that any other Control has, plus a few others derived from System.Web.UI.TemplateControl, which is its immediate Base class.
What seems to confuse people who are new to ASP.Net is that while the conceptual model has changed, the platform has not. We're still dealing with HTTP and HTML here, and the control's interface element is just text streamed to the browser. Part of the problem that people have may stem from the way that these controls appear in Visual Studio.NET, and how they appear in the source code for an ASP.Net page. In Visual Studio.NET's IDE, the HTML for Controls is rendered, making it look like there's actually something there. But there's not. If you view the code for the control in the HTML view, you will notice that there is NO HTML for the Control in the page. This is because the Control renders HTML to the page when the page is executed. One of the Event methods that a Control has is the Render() Method. This method literally writes HTML for the control into the HTML output stream of the Page.
Don't let this confuse you, however. Underneath it all, ASP.Net is simply automating much of what you had to hand-code into your ASP applications. It is still writing HTML to the output stream to the browser. Part of the output stream, however, is certain types of HTML elements, such as the client-side event handlers that call the __doPostBack() function, the ViewState hidden form field, and __doPostBack() JavaScript, which are used to emulate the link between the client and server, enabling client-side events to trigger server-side event handlers.
By creating the idea of a WebForm, all of this is brought together into a programming model which acts much like a Windows Form. A Windows Form handles its own events. A WebForm does this too, by sending event messages with a POST to the server, which then streams back the updated state of the WebForm. This is why a WebForm always posts back to itself.
Conclusions: In many ways, ASP.Net is an entirely different animal than ASP. But underneath it all, ASP.Net is still doing everything that ASP does, just in a more organized and object-oriented way. ASP.Net automates many of the common tasks demanded from an ASP developer, and hides much of the automation from the developer, as any good object-oriented technology should.
A WebForm (Page Class) is the ASP.Net equivalent of a Windows Form. It has similar programming characteristics to a Windows Form. The back-end and interface elements, however, are separated by the "gulf" of the Internet and stateless HTTP protocol. To bridge that gap, elements have been introduced on the client- and server-sides, to enable event and state messaging between the client interface and server code.
Footnotes:
1. Server Controls must have their "EnableViewState" property set to True in order to use the ViewState
2. This is true only for Controls which have server-side events, and have their "AutoPostBack" property set to True
Set as Homepage | Add to favorites
