Using inheritance with ASP.NET pages

I go back to work full time next Tuesday.  My terminal leave is almost up, I’m a civilian, and my new office furniture will be arriving today. 🙂 

Yesterday I was visiting with two colleagues of mine, and I was struck with a surprising reality:  They were programming with ASP.NET but had no idea that they were using inheritance.  One of the two was a former college professor of mine from whom I learned a great deal of database knowledge.  I pondered on it for a while, and I think that there are probably many out there that don’t yet know how to use the power of inheritance to improve their .Net web applications.  I will now attempt to simply explain an easy way one can easily improve a page using inheritance.

First, when you write code in an ASP.NET page, you are writing code in a class that is inheriting from another class.  Whether it’s specified in the machine.config, web.config or in the <@Page> directive at the top of the page, your page has to inherit from a class that ultimately will inherit from System.Web.UI.Page.  When you use the code-behind or code-beside technique, your page inherits from your code-behind class, which inherits from System.Web.UI.Page.  Look at the class.  Why else do you see “System.Web.UI.Page” in every code-behind page?  It makes your page contain the functionality of the Page class in the .Net framework.  It makes your page a System.Web.UI.Page object.  The Page object contains the properties for accessing Request, Response, Server, Cache, etc. 

Suppose you want to implement tracking for some of your pages?  You could put relevant code in every page, or make a static method in a shared class to track the current request.  But why not put this functionality in a class by itself, say “TrackedPage”.  When you declare TrackedPage, inherit from System.Web.UI.Page:

public class TrackedPage : System.Web.UI.Page{ }

and in your code-behind page, replace the reference to System.Web.UI.Page with “TrackedPage”.  This will make your page a “TrackedPage” object and will benefit from any logic you put in TrackedPage.  For instance,

public class TrackedPage :  System.Web.UI.Page{
protected override void OnInit(EventArgs e)
   //logic to track this request
   Trace.Write(“Tracking“, “This request has been tracked.“);

will perform your tracking logic and write a line to the trace log for every page that inherits this custom class of yours.  You can imagine all the functionality you can include.  What if you have a custom user object that you need to be available for every request?  Make it a property of your class here, and make it the base page for all your pages? 

I find that a lot of people make user controls to encapsulate common functionality.  This is not a good technique.  Instead, put it in base pages and inherit from them.

My project on GotDotNet makes heavy use of this technique, and it’s easy to extend EZWeb because all you have to do is inherit from Palermo.EZWeb.UIPage, and you have all the functionality available.