Eric Wise

Sponsors

The Lounge

Wicked Cool Jobs

Blogs I Read

Fun & Games

Advertisement

Images in this post missing? We recently lost them in a site migration. We're working to restore these as you read this. Should you need an image in an emergency, please contact us at imagehelp@codebetter.com
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.


Posted Wed, Feb 2 2005 12:11 PM by Eric Wise

[Advertisement]

Comments

Raymond Lewallen wrote re: ASP .NET BasePages - Level 100
on Wed, Feb 2 2005 12:46 PM
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.
Sahil Malik wrote re: ASP .NET BasePages - Level 100
on Wed, Feb 2 2005 1:08 PM
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 :)
TrackBack wrote Expanding on ASP.NET BasePages from Eric Wise
on Wed, Feb 2 2005 3:25 PM
TrackBack wrote Expanding on ASP.NET BasePages from Eric Wise
on Wed, Feb 2 2005 3:30 PM
David M. Kean wrote re: ASP .NET BasePages - Level 100
on Wed, Feb 2 2005 10:57 PM
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.
Eric Wise wrote re: ASP .NET BasePages - Level 100
on Thu, Feb 3 2005 7:00 AM
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.
TrackBack wrote How do you like CodeBetter.com so far?
on Mon, Feb 14 2005 5:56 PM
TrackBack wrote How do you like CodeBetter.com so far?
on Mon, Feb 14 2005 5:58 PM
TrackBack wrote State Class Management Presentation on March 7th
on Wed, Feb 16 2005 11:45 AM
Brock Allen wrote re: ASP .NET BasePages - Level 100
on Wed, Feb 16 2005 4:23 PM
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.
Eric Wise wrote re: ASP .NET BasePages - Level 100
on Wed, Feb 16 2005 4:34 PM
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.
Brock Allen wrote re: ASP .NET BasePages - Level 100
on Wed, Feb 16 2005 5:47 PM
Sure Eric; Mechanically it all works. I just feel it's not the best approach. To each his/her own :)
Devlicio.us