Table of Contents:

• Introduction
• HTTP Thin-client Applications
• HTTP State Considerations
• How ASP Maintains State
• How ASP.Net Maintains State
• How ViewState Works
• ASP.Net and Events
• ASP.Net Controls

• Conclusions
Introduction: 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 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:

1. Data passed back from client browser is passed back to client browser.
2. 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:

<%
Dim strSelection

strSelection = Request.Form("mySelect")

%>
<select size="1" name="mySelect">
     <option value="This" <%if strSelection = "This" then Response.Write 
"selected"%>>This
     </option>
     <option value="That" <%if strSelection = "That" then Response.Write 
"selected"%>>That
      </option>
     <option value="The Other" <%if strSelection = "The Other" then 
Response.Write "selected"%>>The
     Other</option>
</select>

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:

<input type="hidden" name="__EVENTTARGET" value="" />
<input type="hidden" name="__EVENTARGUMENT" value="" />
<input type="hidden" name="__VIEWSTATE" value="dDwxMzkwODg5OTYwO3Q8O2
w8aTwxPjs+O2w8dDw7bDxpPDE+O2k8NT47aTw3Pjs+O2w8dDxwPGw8aW5uZXJodG1sOz47
bDxTYXR1cm4gb2YgS2Fuc2FzIENpdHk7Pj47Oz47dDw7bDxpPDE+Oz47bDx0PDtsPGk8MT4
7PjtsPHQ8O2w8aTwwPjtpPDE+Oz47bDx0PDtsPGk8MT47PjtsPHQ8dDw7O2w8aTwwPjs+Pjs
7Pjs+Pjt0PDtsPGk8MT47PjtsPHQ8dDw7O2w8aTwwPjs+Pjs7Pjs+Pjs+Pjs+Pjs+Pjt0PHA
8cDxsPFZpc2libGU7PjtsPG88dD47Pj47Pjs7Pjs+Pjs+PjtsPHJhZGlvU25hcDtyYWRpb1
Njcm9sbEhvcml6O3JhZGlvU2h1dHRlcklyaXM7cmFkaW9EaXNzb2x2ZTtyYWRpb1Njcm9sb
FZlcnQ7cmFkaW9TaHV0dGVySG9yaXo7Pj4KEPaAB1EZ35xbda79s7LeNJzpXw==" />

<script type="text/javascript">
<!­­
function __doPostBack(eventTarget, eventArgument) {
var theform = document.Form1;
theform.__EVENTTARGET.value = eventTarget;
theform.__EVENTARGUMENT.value = eventArgument;
theform.submit();
}
// ­­>
</script>

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.