One of the hallmark features of object-oriented development
is inheritance. It allows you to utilize features from one object in another.
For example, inheritance plays a vital role when creating new custom controls
in .NET (the Control class is the base class). In addition, you can take
advantage of inheritance in ASP.NET applications. A good example is creating a
base page class that includes common features. In turn, this base page class
can be used when creating new pages. Let’s take a closer look at this concept
in action.

The creation of a page

When a client requests an ASP.NET page, the code executed on
the server is comprised of more than the code you created for it. At run time
(when the page is requested), ASP.NET generates and compiles one or more
classes that actually perform the tasks required to execute the page.

An ASP.NET page runs as a unit. The server-side elements are
combined with any event-handling code. The pages are dynamically compiled and
run the first time they are requested. The class or classes that the compiler
creates depends on whether the page uses the single-file or code-behind model.

In a single-file page, the markup, server-side elements, and
event-handling code are contained in a single .aspx
file. Upon page compilation, a new class derived from the base System.Web.UI.Page class.

Conversely, the code-behind model is more intricate. The
page’s markup and server-side elements are contained in the standard .aspx file. The page’s code is in a separate code file, and
it contains a partial class. You add your custom code to this partial class.

The creation of a code-behind page

As you may have guessed, the inheritance model for
code-behind pages is more elaborate. First, the code-behind partial class is
declared; it may inherit from the standard System.Web.UI.Page
or from another class that extends it. Next, the .aspx
file points to the partial class. Upon compilation, a partial class is created
for the .aspx file. It is a peer of the code-behind’s
partial class. The final step is the generation of the class that encompasses
everything from the partial classes, which is then compiled into an assembly.

While the code-behind model is still available in ASP.NET
2.0, it isn’t the default when using Visual Studio. The default deployment model
in ASP.NET 2.0 is to compile pages in place. You still have partial class files
when using the code-behind approach. This means that control declarations are
generated at compile time and not at design time, which means they are always
in sync. Therefore, you won’t encounter any more issues where a control exists
in the ASPX page, but not in the source code. We will stick with the current
approach (ASP.NET 1.1) as previously described in this article.

Extending the page class

With the details of page compilation firmly entrenched in
our minds, let’s move forward with developing a custom class to share features
across pages.

For this article, the base page will include a simple
JavaScript function that opens a file in a separate window. In addition, the base
page will specify the cache settings for the page.
Listing A contains the C# code for the base page. (If you want to
check out the VB.NET equivalent of this code, view
Listing B.)

Here are a few points about the code:

  • It
    extends the System.Web.UI.Page class.
  • The Page_Load event makes two calls: cache settings for
    the page and register a script.
  • The SetCacheAbitlity call indicates that the content is
    cached at the server but all others are explicitly denied the ability to
    cache the response.
  • The RegisterClientScriptBlock method of the System.Web.UI.Page class emits a client-side script
    block. The first parameter assigns a key to script block. By identifying
    the script with a key, multiple server control instances can request the
    script block without it being emitted to the output stream twice. Any
    script blocks with the same key parameter values are considered
    duplicates.
  • The OnInit method of the base Page class is called to
    ensure no processing is overlooked.

With this class defined, it may be reused in other pages.
So, it may be specified as the base class for a new page instead of the default
System.Web.UI.Page class. All pages that need this
functionality may be declared like this in C#:

public class WebForm1 : BasePage

and like this in VB.NET:

Public Class WebForm1

Inherits System.Web.UI.Page

Extend it even further

With our base class intact, we can fully take advantage of
the power of inheritance by extending it. That is, new classes may be created
that use our custom class as its base. This means that other developers on your
team may further extend the class to use the base functionality, as well as
additional functionality for other pages. You could create a new class in C#:

public class NewPage : BasePage

or in VB.NET:

Public Class NewPage

Inherits BasePage

The power is in your hands

Using inheritance to create pages with functionality common
throughout a site/application allows you to fully utilize the features of the
.NET platform and object-oriented concepts. It provides a central location to
work with common site features, which in turn, saves you time and promotes code
reuse.

TechRepublic’s free .NET newsletter, delivered each Wednesday, contains useful tips and coding examples on topics such as Web services, ASP.NET, ADO.NET, and Visual Studio .NET. Automatically sign up today!