IntroductionOne of the many benefits of object-oriented programming is that it allows for reuse of logic. For example, classes can be created that contain a base level of functionality. These base classes can then be extended through inheritance to create new classes that encompass the functionality of the base class along with any custom logic needed. The end result is that as a developer, once the base class has been created, you can extend and enhance the functionality of the base class with minimal effort.
Since the .NET Framework is built upon the principles of object-oriented programming (OOP), it's no surprise that ASP.NET borrows heavily from the tenets of OOP, one such tenet being inheritance. The base functionality for all ASP.NET pages is spelled out by the Page class in the System.Web.UI namespace. This class defines the essential properties, methods, and
events for an ASP.NET page, including such members as:
- The intrinsic objects - Response, Request, Session, and so on,
- Common properties - IsPostBack, IsValid, and others,
- Methods used throughout the page lifecycle, such as SavePageViewState(),
ProcessRequest(), RaiseChangedEvents(), and others.
While all ASP.NET pages must be derived from the Page class, they need not be directly derived. That is, an ASP.NET page may extend a class that, itself, extends the Page class.
In fact, when using the code-behind model for creating ASP.NET pages the actual ASP.NET page
is derived from the code-behind class, with the code-behind class being derived from the Page class.
/***********
Why I had used *****************************/
Let me describe why I had used base class.
I have a website of around 100 pages; most of the pages are only available after login.
To restrict unauthorized access to pages generally we check for session values.
I have a session variable which contains a value, if that variable is null I have to assume this is an unauthorized user.
Now, what I had done to resolve the problem I had made a base class which will contains my code of checking session variables and redirect to login page. Then I had simply inherited page from the page base class to reduce my code and increase efficiently of website
download code which I had written to use base class/*******************************************/
In fact, oftentimes it makes sense to create a base class for a particular ASP.NET Web application that extends the Page class and have all code-behind classes derive from this class, rather than directly from the Page class. This universal base class can contain its own properties, methods, or events that are common to all pages in the particular ASP.NET application, or it can extend the functionality of existing methods or properties.
Regardless of whether the code-behind model or inline script model is used, when the .aspx page is visited, the ASP.NET engine translates the markup section into a class and then compiles that class. If the code-behind model is being used, then the auto-generated class is derived from the page's corresponding code-behind class. On the other hand, if the inline script model is being used then the auto-generated class is derived directly from the Page class. The following diagram illustrates the resulting type graph used by both models.
Regardless of whether the code-behind model or inline script model is used, when the .aspx page is visited, the ASP.NET engine translates the markup section into a class and then compiles that class. If the code-behind model is being used, then the auto-generated class is derived from the page's corresponding code-behind class. On the other hand, if the inline script model is being used then the auto-generated class is derived directly from the Page class. The following diagram illustrates the resulting type graph used by both models.
The Basics of a Base ClassAs the type graph examined above shows, the auto-generated ASP.NET page class must extend the Page class, but can do so indirectly, through a code-behind class, for example. But there's no reason why there can only be one level of encapsulation between the auto-generated class and the essential Page class. You can optionally create a base class from which all pages will derive from. When creating a base class, you'll typically have this base class extend the Page class. If you are using the code-behind model your code-behind classes will need to be modified to inherit from the new base class as opposed to the Page class. If you are using the inline script block model, you'll need to use the @Page directive's Inherits keyword to specify the type name of the class you want the auto-generated class to extend. With a custom base class the type graph for an ASP.NET page morphs into the one shown below:
As you can see in the type graph, the base class must derive from the Page class. ASP.NET page's that want to utilize the functionality of the base class will derive from this base class rather than from the Page class directly.
When creating a base class you might decide to add additional properties or methods, which are as simple as adding the appropriate properties and methods to the base class itself. Additionally, you'll likely need to extend the functionality of the Page class, adding logic at particular points in the page's lifecycle, such as common code that should run in response to the Page's Load event. To accomplish this, you'll want to override the appropriate method: OnInit to respond to the Init event; OnLoad to respond to the Load event; and OnPreRender to respond to the PreRender event.
