ASP.NET Introduction

 

Chapter 14 - ASP.NET Pages
bySimon Robinsonet al.
Wrox Press 2002

  

ASP.NET works with Internet Information Server (IIS) to deliver content in response to HTTP requests . ASP.NET pages are found in .aspx files, and the basic architecture looks like this:

During ASP.NET processing we have access to all .NET classes, custom components created in C# or other languages, databases, and so on. In fact, we have as much power as we would have running a C# application using C# in ASP.NET is in effect running a C# application.

An ASP.NET file may contain any of the following:

• Processing instructions for the server

• Code in C#, VB.NET, JScript.NET, or any other language that the .NET Framework supports now or might support in the future

• Content in whatever form is appropriate for the generated resource, such as HTML

• Embedded ASP.NET server controls

So, in fact we could have an ASP.NET file as simple as:

   Hello!   

with no additional code or instructions at all. This would simply result in an HTML page being returned (as HTML is the default output of ASP.NET pages) containing just this text.

As we will see later in this chapter, it is also possible to split certain portions of the code into other files, which can provide a more logical structure.

State Management in ASP.NET

One of the key properties of ASP.NET pages is that they are effectively stateless. By default, no information is stored on the server between user requests (although there are methods for doing this should you wish, as we'll see later). At first glance this seems a little strange , as state management is something that seems essential for user-friendly interactive sessions. However, ASP.NET provides a rather nice way around this problem, in such a way as to make session management almost completely transparent. It just happens.

Basically, information about, for example, the state of controls on a Web Form (such as data entered in textboxes, or selections from drop-down lists) is stored in a hidden viewstate field that is part of the page generated by the server and passed to the user. Subsequent actions, such as triggering events that require server-side processing like submitting form data, result in this information being sent back to the server, known as postback . On the server this information is used to repopulate the page object model allowing us to operate on it as if the changes had been made locally.

We'll see this in action shortly and point out the details.