Establish common ASP.NET page features through inheritance

The object-oriented nature of the .NET Framework simplifies many development tasks. One such task is using common elements within ASP.NET pages. Here's how to create a base page to share functionality across a site or application.

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!

About Tony Patton

Tony Patton has worn many hats over his 15+ years in the IT industry while witnessing many technologies come and go. He currently focuses on .NET and Web Development while trying to grasp the many facets of supporting such technologies in a productio...

Editor's Picks

Free Newsletters, In your Inbox