CodeBetter.Com
CodeBetter.Com
RSS 2.0 via Feedburner
           Do you Twitter? Follow us @CodeBetter

Eric Wise

Business & .NET

ASP .NET BasePages - Level 100

Anyone who is new to the world of ASP .NET, or new to the concepts of inheritence in general probably is missing out on a great way to organize their ASP .NET application.  When you first create a webform and switch to code view you are faced with the following statement (c#):

public class YourPage : System.Web.UI.Page

What many new coders do not realize is that they can create class files that inherit System.Web.UI.Page and embed common functionality into those pages.  Shown here is a sample of a new class BasePage that inherits System.Web.UI.Page.  Notice that it exposes a property called connectstring which would allow any pages that inherit BasePage to already have a lookup for the connection string.

    public class BasePage : System.Web.UI.Page
    {
        private string _connectstring = "";
        protected string connectstring
        {
            get
            {
                if(_connectstring == "")
                {
                    //Get Connection string
                }
 
                return _connectstring;
            }
        }
  
        public BasePage()
        {
            //
            // TODO: Add constructor logic here
            //
        }
    }

All you have to do to inherit the BasePage is to change:

public class YourPage : System.Web.UI.Page   To    public class YourPage : BasePage

A common question I get from new developers when I present this concept to them is “How can I tell when something should be moved to a base page?”.  For me personally, if a segment of code is used more than twice, it goes into a BasePage.  Keep in mind that through the power of inheritance you can create a top level BasePage which has functions common to the majority of the application and Inherit the BasePage class into more page specific classes.  For example:

If the above represented a theoretical order taking system you could group common order functionality into the OrderPage class, the customer functionality into the CustomerPage class, and the Administrator functions into the AdminPage class.  By inheriting one of these classes you can gain access to the special functionality they provide.  The end result is code organization that is clean and easy to follow.



Comments

Raymond Lewallen said:

Something else I always do for an Asp.Net project, is create a singleton type for handling the session in the same namespace or assembly as the BasePage type. I then have declaration in the BasePage type:

public ApplicationSessionManager UserInstance;

I then create a sub in BasePage called PreInit or whatever, that handles System.Web.UI.Page.Init where I define UserInstance, such as:

UserInstance = ApplicationSessionManager.Instance;

where ApplicationSessionManager.Instance is the property returning the singleton ApplicationSessionManager type.

For me this works out very well because project programming standards can now forbid accessing Session directly and force the use of the UserInstance defined in the base class, which means I always know exactly what is going to exist in the session object because its controlled by the ApplicationSessionManager class.
# February 2, 2005 12:46 PM

Sahil Malik said:

Thats kinda neat man !!

You might already know this, but ASP.NET 2.0 Beta1, totally screwed up the above concept. But Beta2 finally fixed it out ..

Wait I'll blog about the rest :)
# February 2, 2005 1:08 PM

TrackBack said:

# February 2, 2005 3:25 PM

TrackBack said:

# February 2, 2005 3:30 PM

David M. Kean said:

Good idea, however I don't like the example given, your pages shouldn't really known about connection strings, that should be the job of the datalayer.
# February 2, 2005 10:57 PM

Eric Wise said:

David,

Yes, in normal cases that would be true. However this code was taken from a system where different users had different databases so the connection string wasn't driven by the data layer but by the ASP .NET user.

In addition, with the encrypted sections of the ASP.NET 2.0 web.config file I do believe that many websites will end up querying the web.config so for them this method would be valid.
# February 3, 2005 7:00 AM

TrackBack said:

# February 14, 2005 5:56 PM

TrackBack said:

# February 14, 2005 5:58 PM

TrackBack said:

# February 16, 2005 11:45 AM

Brock Allen said:

This sounds great in theory, but in practice it doesn't work out so well. What if your User Control now needs the connection string? I think it's much easier to have "common functionality" in static methods in some common utility class. The OO model in ASP.NET is completely wrong anyway, so just because they followed with that bad approach doesn't mean it's a good design.
# February 16, 2005 4:23 PM

Eric Wise said:

Brock,

You can actually create a BaseControl class to inherit from that allows you to access the parent page object and get to that common functionality.
# February 16, 2005 4:34 PM

Brock Allen said:

Sure Eric; Mechanically it all works. I just feel it's not the best approach. To each his/her own :)
# February 16, 2005 5:47 PM

Leave a Comment

(required)  
(optional)
(required)  

Enter the numbers above:
Add
Check out Devlicio.us!

Our Sponsors

Free Tech Publications