ASP.NET Architecture, Part 1

In this first of a two-part series, Dwight takes us through the new ASP.NET Architecture. We learn about ASP.NET's System.Web.UI namespace classes, interfaces, enumerations, and delegates. We also learn about the ASP.NET page class, including a close look at the life cycle of an ASP.NET page, applying page directives, and the code-behind feature. This piece comes from chapter six of this month's Developer Shed Writing Contest prize, .NET & J2EE Interoperability, by Dwight Peltzer (McGraw-Hill/Osborne, ISBN 0-07-223-054-1, 2004).

Contributed by McGraw-Hill/Osborne
Rating:

/ 50
February 23, 2004

Rate this Article:
MEH MEH++

SEARCH ASP FREE

ASP.NET Namespaces

The path to understanding ASP.NET’s process lies in examining the underlying infrastructure and observing how ASP.NET interacts with the .NET Framework base-class libraries and namespaces. The Framework supports web services and web forms through namespaces that host classes, such as System.Web.UI and System.Web.UI.WebControls. The System.Web.UI namespace contains classes and interfaces that allow you to create controls and pages that appear in your web applications as user interfaces on a web page. A major advantage offered by ASP.NET is running the controls on the server rather than on the client so you can programmatically control them at runtime.

System.Web.UI Namespace

The System.Web.UI namespace hosts the classes and interfaces especially designed for rendering elements on a web form. You can view all classes in the System.Web.UI namespace as a hierarchical tree beginning with the Control class. This is the mother of all controls. Buttons, text boxes, drop-down list boxes, and so on, derive from the Control class. It encapsulates both functionality and user interface properties for all member controls residing in this namespace. Class properties include Controls, Context, ClientID, EnableViewState, ID, NamingContainer, Parent, Site, TemplateSourceDirectory, UniqueID, Visible, and ViewState.

A collection of classes, interfaces, enumerations, and delegates makes up the namespace and are essential for developers to understand so that they can take full advantage of ASP.NET.

System.Web.UI Namespace Classes

This table provides a complete list of System.Web.UI classes:

Class	Description
Attribute Collection	Provides all object-model access declared in the openingtag of an ASP.NET server control element. The class cannot be inherited.
BaseParser	Offers a base set of functionality for classes involvedin parsing ASP.NET page requests as well as server controls.
ConstructorNeedsTagAttribute	Requires a tag name in the server control constructor.
Control	Defines all properties, methods, and events shared by all ASP.NET server controls.
ControlBuilder	Supports the page parser in constructing a control and its child controls.
ControlBuilderAttribute	Specifies a ControlBuilderClass for constructing a custom control within the parser. The class cannot be inherited.
ControlCollection	Provides a collection container for ASP.NET to maintain a list of its child controls.
CssStyleCollection	Contains the HTML cascading style sheets inline style attributes for a specified HTML server control.
DataBinder	Lends support for RAD developers to generate and parse data-binding expression syntax. This class cannot be inherited.
DataBinding	Contains information about a single data-binding expression in a server control. This feature enhances RAD development and allows developers to create data-binding expressions at design time.
DataBindingCollection	Provides a collection of DataBinding objects for an ASP.NET server control. This class cannot be inherited.
DataBindingHandlerAttribute	Defines a design-time class that performs control data binding within a designer. This class cannot be inherited.
DataBoundLiteralControl	Creates a control for HTML text to enable handling of <% %> data-binding expressions processed by the ASP.NET server. This class cannot be inherited.
EmptyControlCollection	Lends support for an empty control collection.
HTML32TextWriter	Provides a text writer for ASP.NET pages and server controls that render HTML content for HTML 3.2 clients.
HTMLTextWriter	Writes a sequential series of HTML-specific characters and text to a web forms page. The class enables formatting capabilities used by ASP.NET server controls when rendering HTML content to clients.
ImageClickEventArgs	Provides information for events occurring when a client clicks on an image-based server control. This class cannot be inherited.
LiteralControl	Represents HTML elements, text, and other strings on an ASP.NET page not requiring server-side processing.
LosFormatter	Serializes the view state for a web forms page. This class cannot be inherited. . This class cannot be inherited.
Page	Defines an .aspx file or a web forms page. All other pages derive from the ASP.NET page class in the System.Web.UI namespace.
Pair	Contains two objects that can both be added to an ASP.NET server control’s view state.
ParseChildrenAttribute	Defines a metadata attribute that a developer uses when developing ASP.NET server controls. Use this attribute to indicate whether XML elements embedded within the ASP.NET server control’s tags should be treated either as properties or as children when the control is used declaratively on a page control. This class cannot be inherited.
PartialCachingAttribute	Represents a class created when a user control (.ascx file) is specified for output caching, using either the @ OutputCache directive or the PartialCachingAttribute, and is added to the page programmatically.
PersistChildrenAttribute	Defines a metadata attribute utilized by ASP.NET server controls. The attribute specifies whether, at design time, the child controls of an ASP.NET server control should be persisted as nested inner controls. This class cannot be inherited.
PersistenceModeAttribute	Defines a metadata attribute that specifies how an ASP.NET server control property or event is persisted to an ASP.NET page. This class cannot be inherited.
PropertyConverter	Contains helper functions to convert property values to and from strings.
StateBag	Manages the view state of ASP.NET server controls, including pages. This class cannot be inherited.
StateItem	Represents an item that is saved in the StateBag class when view state information is persisted between web requests. This class cannot be inherited.
StaticPartialCachingControl	Represents an instance of the UserControl class when it has been specified for output caching and included declaratively in a page or another user control.
TagPrefixAttribute	Defines the tag prefix used in a web page to identify controls. This class cannot be inherited.
TemplateBuilder	Supports the page parser when constructing a template and child controls that it contains.
TemplateContainerAttribute	Declares the type of the INamingContainer that will contain the template once it is created.
TemplateControl	Provides the Page class and the UserControl class with a base set of functionality.
ToolboxDataAttribute	Specifies the default tag generated for a custom control when it is dragged from a toolbox in a tool, for example, Visual Studio.
Triplet	Holds three objects that can all be added to an ASP.NET server control’s view state.
UserControl	Represents an .ascx file, requested from a server that hosts an ASP.NET web application. The file must be called from a web forms page, or a parser error will occur.
UserControl ControlBuilder	Supports the page parser when constructing a user control and any child user controls that it contains.
ValidationPropertyAttribute	Defines the metadata attribute used by ASP.NET server controls to identify a validation property. This class cannot be inherited.
ValidationCollection	Exposes an array of IValidator references. This class cannot be inherited.

System.Web.UI Namespace Interface, Enumerations, and Delegates

Interfaces

The following table contains the list of the System.Web.UI interfaces:

Interface	Description
IAttributeAccessor	Defines methods used by ASP.NET server controls to provide programmatic access to any attribute declared in the opening tag of a server control.
IDataBindingsAccessor	Permits access to the collection of data-binding expressions on a control at design time.
INamingContainer	Identifies a container control that creates a new ID namespace within a Page object’s control hierarchy. This is a marker interface only.
IParserAccessor	Defines the method that ASP.NET server controls must implement to recognize when elements, either XML or HTML, are parsed.
IPostBackDataHandler	Defines methods that ASP.NET server controls must implement to automatically load post-back data.
IStateMapper	Defines properties and methods that any class must implement to support view state management for a server control.
ITemplate	Defines the method to implement for populating an ASP.NET server control with child controls when using a control with inline templates declared in an .aspx file.
IUserControlDesignerAccessor	Defines the properties to implement, and allows designers to access information about a user control at design time.
IValidator	Defines the properties and methods that objects participating in web forms validation must implement.

Enumerations

The following table provides a list of System.Web.UI enumerations used when enumerating more than one item.

Enumeration	Description
HtmlTextWriterAttribute	Specifies the HTML attributes that an HTMLTextWriter or HTML32TextWriter object writes to the opening tag of an HTML element when a web request is processed.
HtmlTextWriterStyle	Specifies the HTML styles available to an HtmlTextWriter or HtmlTextWriter32 object output stream.
HtmlTextWriterTag	Specifies which HTML tags are allowed to be passed to an HtmlTextWriter or HtmlTextWriter32 object output.
OutputCacheLocation	Specifies the valid values for the location of the output cache.
PersistenceMode	Specifies how an ASP.NET server control property or event is persisted declaratively in an .aspx or .ascx file.

Delegates

The final item in the System.Web.UI namespace, delegates, contains one item. It describes the method that handles any events raised when a user clicks on an image-based ASP.NET server control. Also, a delegate is a reference type that encapsulates a method that contains a specific signature and return type.

ASP.NET Page Class

ASP.NET pages begin as code in a text file with an .aspx extension. They lie within an Internet Information Service (IIS) virtual directory located somewhere on your LAN or on a remote server. Pages are instantiation classes derived from the parent Page class. For example, you can write your code using any text editor such as Notepad or, preferably, Visual Studio .NET. The text file becomes a valid ASP.NET page only when a client sends a request to the server to render the page to the client browser. The page compiles to a class. It is created at runtime as a Page object and is subsequently cached in memory. It naturally follows that the Page object serves as a naming container for all server controls embedded within the page. The only exception to this is those server controls implementing the INamingContainer interface. Examining the Page Class

ASP.NET functionality lies primarily with the Page class. Every page derives from the Page class, thereby inheriting all the methods and properties the Page class exposes. The following list describes several members of this class.

The ASP objects such as Application, Session, Request, Response, Server, and Context are implemented in ASP.NET as class instances, which are exposed as properties of a specified page.
The Controls collection provides access to the set of controls defined for a specific page. With this collection, you can add or alter controls.
The IsPostBack property is used to determine whether the current request is a GET request or a POST request.
The User property provides information about the logged-in user.
The Cache property enables access to the ASP.NET cache engine. You can use this property to allow data to be cached for later retrieval.
The FindControl property allows you to locate a control in the Controls collection by specifying the ID attribute property.
The ViewState property allows you to store a page’s state in a hidden form field (key-value pair) between client requests.
The ClearChildViewState property allows you to delete view state information for any child controls residing on a page.

Two methods exist for inheriting from the Page class: the first is adding the @ Page directive to an .aspx file. By doing so, the directive automatically makes available all page properties and methods for any code written on the page.

<%@ Page Language ="vb"%>

The second method uses the code-behind feature to inherit from the Page class associated with a particular page by specifying either the Src or Inherits attribute:

<%@ Page Language="vb" AutoEventWireup="false"
Codebehind="RegisterForm.aspx.vb"
Inherits="RegisterForm.WebForm1" %>

The second method allows ASP.NET to combine the code in the web form’s .aspx file with the code in the code-behind class file and compile both files to a single merged file at compile time.

An ASP.NET Page's Life Cycle

Let’s examine a page’s life cycle to further our knowledge of ASP.NET pages. Figure 1 illustrates the page’s process from its inception to its destruction.

ASP.NET Life cycle

Figure 1 An ASP.NET page’s life cycle

Each ASP.NET page contains a server-side <form> tag. This tag directs the page to post back to itself when a client submits the form. The Form type events include Load, Draw, Render, and Unload.

ASP.NET controls also render JavaScript to the client, enabling actions such as selecting a specified item from a drop-down list, thereby causing a post back to the server. The ASP.NET runtime also renders a hidden form field to the page and allows it to preserve its state between client requests.

Note: The engagement between client and page in the case of hidden form fields occurs on the client side, rather than on the server.

Because ASP.NET is event driven, client and page interaction allows the page to be reconstructed on the server. It also permits code execution in response to events raised by users and any changes occurring in the hidden fields.

The initial event begins with an HTTP URL client request for rendering a specific page to a client’s browser. The Load event fires next. Here is where the CLR uses reflection to examine the .aspx page and see if the page is called for the first time, or whether this represents a post back through user interaction with a button or some other page control. If the event is a first-time request, the code is converted to a class. Subsequently, the class compiles to an assembly and is stored in a valid Internet Information Server virtual directory where the page can be located. However, if the page is posted back, ASP.NET restores any data residing in hidden fields (ViewState) and passes the information to the server. The control event triggering the post back then fires. At this point, all control events are initiated. The change events fire first; those events are stored in the browser and execute only when the client sends the page back to the server. After a control event fires, the page is rendered to the browser.

Before Page_Unload() unloads the page from server memory, a final event performs any cleanup tasks before the unload method disposes of the page.

NOTE: A dynamically generated assembly is not static. If you modify any application code in the .aspx page, the DLL is regenerated the next time the page is called before storing it again to the disk. Latency is an issue here. For example, in a network, latency is a delay. Latency could be solved by multithreading. The browser will respond to callbacks and DLL regeneration.

Applying Page Directives

Most likely if you are a classic ASP developer, you have used directives such as @ Include and @ Language. The @ Include directive instructs the ASP runtime to include a particular file inline with the page. The @ Language directive tells the runtime to employ a specific script interpreter located within the <% %> render blocks. Directives provide easy ways for developers to determine declaratively how various aspects of an application will ultimately behave. For example, in addition to the @ Language directive, classic ASP provided only four directives:

@ Codepage Used in globalization to set the code page for an ASP page
@ EnableSessionState Used to disable session state for a specified page
@ LCID Used to set the locale identifier for an ASP page
@Transaction Used to specify how a page participates in COM+ transactions

ASP.NET has added numerous directives for controlling page behavior, page configuration, and many other tasks. Table 6-1 presents a partial list of new directives included with ASP.NET. Note that in the Values column, T/F stands for true or false.

Attribute	Values	Meaning
@ Page	T/F	Defines page-specific attributes used by ASP.NET compilers and the CLR to determine page behavior.
AutoEventWireup	T/F Default is set in the <pages> segment of the Machine.config or Web.config file	Determines whether handlers are set up automatically. Default is true.
Buffer	T/F	Specifies whether rendered output is buffered before sending it to clients, or sent as it is rendered.
ClassName	Can be any class name	Determines name of page when dynamically compiling the page. This works either with or without CodeBehind.
CodeBehind	File name of CodeBehind class	Visual Studio .NET uses this attribute for locating the CodeBehind class and compiling during a build operation. ASP.NET does not use this attribute.
CodePage	Any code page	The same in both ASP and ASP.NET.
CompilerOptions	A string containing valid compiler options	Allows developers to specify compiler options for a specified page.
ContentType	Any valid MIME type	Sets the MIME type for page output.
Debug	T/F Default is set in the <compilation> section of the Machine.config or Web.config file	Determines whether pages are compiled with debug symbols or not. Default is false.
Description	Any string	Provides a text description of the page. The ASP.NET runtime ignores this attribute.
EnableSessionState	T/F Default is set in the <pages> section of the Machine.config or Web.config file	Determines whether a page request initiates a new session and whether or not the page can access or modify data saved in an existing session. Default is true.
EnableViewState	T/F Default is set in the <pages> section of the Machine.config or Web.config file	Specifies whether ViewState is enabled for the page. Default is true.
EnableViewStateMac	T/F Default is set in the <pages> section of the Machine.config or Web.config file	Determines whether ASP.NET executes a machine authentication check on the content of a hidden form field that is used to store ViewState and to ensure it is not modified on the client. Default is false.

Table 1 ASP.NET Page Directives

NOTE: The list of directives in Table 1 is incomplete. Many other equally important directives exist, such as Inherits, ResponseEncoding, LCID, Strict, and Transaction. You can search for these directives in Visual Studio .NET Help.

Here is a brief example of how you would use the Page directive:

<%@ Page debug="true" %>

Another example sets the trace directive:

<%@ Page trace="true" %>

Other directives include the @ Implements directive, employed to implement a defined interface from within an ASP.NET page. In addition, use the @ Register directive to register user controls and custom server controls on an ASP.NET page.

Code-Behind Feature

ASP.NET’s code-behind feature separates business logic from the presentation layer. In order to take advantage of this technique, derive from the Page class. Then place your code in an .aspx file and insert a reference to another file containing the business logic, for example:

<%@ Page Language="vb"%>
<%@ Register TagPrefix="ASPNETSBtn"
TagName="ClientName" Src="RegisterClient" %>

NOTE: Any file referenced with thesrc attribute of the Page directive is compiled into a separate assembly and added to the list of referenced assemblies when the page is compiled. Additionally, an advantage of using thesrc attribute for the code-behind file is the ease with which the developer can update the code-behind file by replacing the file. Subsequently, the next time a page is requested, ASP.NET recompiles the file.

The following example contains HTML, text, and several lines of VB .NET code. The web form has two Textbox controls named FirstName and LastName. The form also contains two RequiredFieldValidator controls that prevent you from submitting the form to the server without entering data in the FirstName and LastName Textbox controls.

NOTE: The <asp: TextBox> tag informs the compiler that this ASP.NET page contains a text box control for execution on the server.

A typical ASP.NET page looks like this:

<%@ Page Language = "vb" AutoEventWireup="false"
Codebehind = "WebForm1.aspx.vb" Inherits="IFCE.WebForm1"%>
<html><head><title>Registering a new client</title></head>
<body>
<form runat="Server">
<p>FirstName:
<br><asp:TextBox id="firstName" runat="Server"/>
<asp:RequiredFieldValidator ControlToValidate="firstName"
Runat="Server"/>
<p>LastName:
<br><asp:TextBox id="lastname" runat="Server"/>
<asp:RequiredFieldValidator
ControlToValidate="lastname"
Runat="Server"/>
<p>
<asp:button text="Submit Form" Runat="server"/>
</form>
</body>
</html>

NOTE: If the <form> element is not present on the page, both web controls and HTML controls will not be able to participate in page post backs, nor will they be able to save their state in the page’s ViewState. They will continue to function otherwise.

It is unwise to bypass one of the key benefits that ASP.NET offers, namely, preserving state between client page requests. Always add the <form> element to your web forms page. If a post-back event occurs, any state stored in hidden fields rendered to the form is retrieved and sent back to the server for rendering the new page to the browser. The user views the newly rendered .aspx page as though it were the original page. In reality, they are two individually unique pages.