Page inheritance in ASP. NET

Introduction

The advent of ASP. net arriving in a world that up to that point had become accustomed to VBSCRIPT or Javascript spaghetti code was the introduction of true, or truer, Object Oriented Programming (OOP) paradigms to web page development. we have seen over the years how to apply objects to facilitate Web Components and controls within ASP. NET applications to automate the process of building out a functional web solution with minimal code. one of the most overlooked features of object orientation, however, is utilizing inheritance with the baseSystem. Web. UI. PageClass.

the most important advantage base page inheritance gives is the ability to enforce security authentication SS all pages that take advantage of the inheritance. you can even specify varying user access levels per page with only one line of code and one tweak of code. the tweak involves replacing the web form's declaration with an inheritance of a new semi-abstract class called commonpage rather than system. web. UI. page .

// create a new. CS file with a commonpage class declaration Public class commonpage: system. web. UI. page { //... }< SPAN class = "CS-comment"> // Replace the standard inheritance declaration of any new web form // with a reference to commonpage Public class webform1: commonpage // changed ": system. web. UI. page " { //... }

By moving to our own base class type, we are now able to customize the base functionality of every web form that inherits this base type, simply by modifyingCommonpage. CS. In this way, all pages subscribing to this base class can also be guaranteed to expose and make available certain properties and methods not as easily available in the previous base class, such as application-specific page, user, or session properties. we can also enforce security checks and clean-up routines that are common clients SS all participant pages.

Specifying minimum access levels

The Natural Initial progression of extending commonpage is to first enforce security. we can guarantee through inheritance and a simple security access level declaration that no user can access a special page without proper security clearance as long as the page inherits commonpage rather system. web. UI. page . this is achieved by customizing the constructor of commonpage and the load event of system. web. UI. page , and thereby executing a new accesscheck method before the web form ever executes.

Public commonpage () { base . load + = New eventhandler (commonpage_load );} private void commonpage_load ( Object sender, eventargs e) {accesscheck ();} private void accesscheck () { // enforce security here... }

At this point, it is now possible to customize the access levels of each page with only a single line of code per page. in order to do this, we must first define a set of access levels withEnumCalledAccesslevel.

<SPAN class = "CS-keyword"> Public </span> <SPAN class = "CS-keyword"> Enum </span> accesslevel {guest = <SPAN class = "CS -literal "> 0 </span>, basemember = <SPAN class = "CS-literal"> 1 </span>, fullmember = <SPAN class = "CS-literal"> 5 </span>, <SPAN class = "CS-comment"> // numerically spaced for future expansion </span> administrator = <SPAN class = "CS-literal"> 10 </span>}

WithAccesslevelDefined, we can now specify a simple field in the web form calledMinlevelThat identifies the clearance level required for the participating web form. Normally, one wowould override a"Minlevel"Property declared inCommonpageAnd customize itsGetMethod.

<SPAN class = "CS-keyword"> Public </span> <SPAN class = "CS-keyword"> class </span> webform1: commonpage {<SPAN class = "CS-keyword"> protected </span> <SPAN class = "CS-keyword"> override </span> accesslevel minlevel {<SPAN class =" CS-keyword "> Get </span> {<SPAN class =" CS-keyword "> return </span> accesslevel. fullmember ;}< SPAN class = "CS-comment"> //... </span>}

This is, of course, considered the most correct way of customizing an access level customization on an inherited web form. however, in order to make this only a single line of code, we can break the paradigm of using overridden properties and instead use a constant field. in our case, our goal is to eliminate as much coding as possible, including even any method or property blocks. so, we instead declare a simple field in the web form that specifies the minimum access level.

<SPAN class = "CS-keyword"> Public </span> <SPAN class = "CS-keyword"> class </span> webform1: commonpage {<SPAN class = "CS-keyword"> Public </span> <SPAN class = "CS-keyword"> const </span> accesslevel minlevel = accesslevel. fullmember; <SPAN class = "CS-comment"> //... </span>}

in order for commonpage to retrieve this value, it must use the system. reflection namespace to discover the value.

<SPAN class = "CS-comment"> // Figure 1 </span> <SPAN class = "CS-keyword"> Public </span> <SPAN class = "CS- keyword "> class </span> commonpage: system. web. UI. page {<SPAN class = "CS-keyword"> private </span> <SPAN class = "CS-keyword"> const </span> accesslevel defaultminlevel = accesslevel. guest; <SPAN class = "CS-keyword"> private </span> <SPAN class = "CS-keyword"> void </span> accesscheck () {accesslevel minlevel = defau Ltminlevel; system. reflection. fieldinfo Fi = <SPAN class = "CS-keyword"> This </span>. getType (). getfield (<SPAN class = "CPP-string"> "minlevel" </span>, system. reflection. bindingflags. public | system. reflection. bindingflags. static | system. reflection. bindingflags. flattenhierarchy); <SPAN class = "CS-keyword"> If </span> (Fi! = <SPAN class = "CS-keyword"> null </span>) minlevel = (accesslevel) Fi. getvalue (<SPAN class = "CS-keyword"> null </span>); <SPAN class = "CS-comment"> //... </SPAN >}< SPAN class = "CS-comment"> //... </span>}

Now,CommonpageKnows the minimum access level for the page. We also specifiedDefaultminlevelConstant to be sure that new inheriting web forms that do not haveMinlevelSpecification can default user access limits to this value. In this way, we can make the default access levelFullmember, For instance, so that by default no new inheriting web form is accessible by anyone limit t that level of user.

Exposing a common user object

now that we have specified an access level for a page, we need to have commonpage map the user's accesslevel . the best way of doing this is to create a whole new user object and keep it stored in the session at all times. we will create an appuser class and have its default accesslevel property set to guest . then we will expose this object as a session-stored property in commonpage that is accessible as currentuser.

<SPAN class = "CS-comment"> // Figure 2 </span> <SPAN class = "CS-keyword"> namespace </span> inheritencesample {<SPAN class =" CS-keyword "> Public </span> <SPAN class =" CS-keyword "> class </span> appuser {<SPAN class =" CS-keyword "> Public </ span> accesslevel level = accesslevel. guest;} <SPAN class = "CS-keyword"> Public </span> <SPAN class = "CS-keyword"> class </span> commonpage: system. web. UI. page {<SPAN class = "CS-comment"> //... </span> <SPAN class = "CS-keyword"> Public </span> appuser currentuser {<SPAN class = "CS-keyword"> Get </span> {appuser USR = (appuser) session [<SPAN class = "CPP-string"> "appuser" </span>]; <SPAN class = "CS-keyword"> If </span> (USR = <SPAN class = "CS-keyword"> null </span>) {USR = <SPAN class = "CS-keyword"> New </span> appuser (); Session. add (<SPAN class = "CPP-string"> "appuser" </span>, USR );} <SPAN class = "CS-keyword"> return </span> USR ;}}}}

At this point, it is very easyAccesscheckMethod inCommonpageTo determine whether the user does not have access to a participant page, with this boolean evaluation:

<SPAN class = "CS-keyword"> If </span> (currentuser. level <minlevel) {<SPAN class = "CS-comment"> //... </span>

By default,AppuserObject's level isGuest. You can customizeAccesscheckMethod so that all guest users attempting to access a more secure page are redirected to a login page that wocould modify the user's access level according to a value specified in a database. in the login page, you can useRequest. servervariables ["http_referer"]To return to the referring page after logging in, or you can pass a more appropriate custom URL in the query string that redirects to the login page, and have the login page default to one and override to the other.

Going further

In addition to applying security, this paradigm makes all new pages derived from yourCommonpageClass universally conformant to the parameters you specify in a single class, or in a few subclasses. For example, you can createCommonxpageClass that inheritsCommonpage, And inheritCommonxpageOnly in web forms that do functionX, So that these have a common minimum security level or a common task to perform when loading, and so forth.

We can also establish universal clean-up routines that are common to all pages in our application, by usingUnloadEvent inCommonpage. (Note that utilizing deconstructors in ASP. NET, or"~ Commonpage (){...}", Is not recommended .)

Public class commonpage: system. web. UI. page { Public commonpage () { base . load + = New eventhandler (commonpage_load); base . unload + = New eventhandler (commonpage_unload );} private void commonpage_unload ( Object sender, eventargs e) { // common clean up... }< SPAN class = "CS-comment"> //... }

All of the benefits of inheritance in Object Oriented Programming apply in ASP. net. hopefully, we have only scratched the surface as to what levels of productiance You Can Take web application development to using inheritance in ASP. net and making the most of OOP methodologies.