Archive for the ‘OOP’ Category

Web Forms Should Inherit a Custom Class

When doing a web application in .NET, I like to create a custom class that inherits from System.Web.UI.Page I usually call this class “MyWebPage”. In some (most) cases, this class doesn’t add any functionality, it’s just a wrapper. However, when you need to do certain things in your web app, this wrapper is invaluable.

When creating web forms, the first thing I do is change the code behind file, so it inherits from “MyWebPage” rather than default System.Web.UI.Page. This gives the new web form whatever functionality is built into “MyWebPage”.

When is this useful? Previously, I talked about dynamic master pages in a CMS application. By overwriting the PreInit method in “MyWebPage” to include the functionality for dynamic web pages, any new template that inherits “MyWebPage” will automatically receive this functionality. The alternative would be to override the PreInit method in every new template.

I first heard about making this page wrapper when Paul Sheriff gave a talk at an Iowa .Net User Group meeting. The example he gave was that you have a large .NET application. On Friday morning, your boss tells you that by Monday, the web application should log every time a page is hit, this log would be something above and beyond what the web server can log. Without the wrapper, you would have to edit every web form in the application, possibly hundreds of files. With the web forms inheriting from your wrapper class, you simply change this one class, and you enjoy the weekend.

Since then, I’ve heard this talked about on .NET Rocks, and also in this blog post by Brian Mishler.


Application Settings

Yesterday, I wrote about wrapping your session state variables into a class. The same thing can be done with other variables such as application settings and connection strings. For this class I normally name the class MySettings.

The code for doing this is very similar to yesterdays code.

public static string mailFrom
    get { return ConfigurationManager.AppSettings["MailFrom"].ToString(); }
public static string calendarConnectionString
    get { return ConfigurationManager.ConnectionStrings["Test"].ToString(); }

As with yesterdays examples, it is then very easy to use these applications settings. When you want to use these settings you’d write one of the following:


Again, this extra class will add a few extra lines of code to your project. However, in the long run it will save you time and effort when you later decide to change something. For example, “Test” is not a good name to call your connection string, so you may want to change it to “CalendarDatabase”. Using this technique, you would change it in your web.config file and in this class, and you’re done. Without this class, you would need to find and replace in your entire source code for the application. What happens when you miss one?

Another advantage of implementing your application settings this way is that Visual Studio’s IntelliSense works with it. I really like IntelliSense!

Wrapping Session States

A common way of using session states in ASP.NET is to simply use the Session object in your code behind file, for example you might say:

Session["MyFirstName"] = "Brian";
Session["MyAge"] = "24";        // Not my real age :-)

Another option would be to wrap these Session states into a class. You’d do this by creating the class, I usually name this class “MySession”, with code that looks like this:

public static string firstName    {
get { return HttpContext.Current.Session["MyFirstName"].ToString(); }
set { HttpContext.Current.Session["MyFirstName"] = value; }
public static int age    {
get { return Convert.ToInt32(HttpContext.Current.Session["MyAge"].ToString()); }
set { HttpContext.Current.Session["MyAge"] = value; }

This give you a few advantages:

  1. You now have all your session states located in a single file in source code.
  2. You access the session states using the MySession.firstName and MySession.age
  3. Because you are using a class, IntelliSense now works! You don’t have to remember that the session state name was “MyFirstName”. All you need to remember is MySession. Visual Studio will give you the rest.
  4. Strongly typed session states. Notice that the type of MySession.age is an integer. It will throw an exception if you try to assign it a value of a different type.

Wrapping your session states into a class may add a little to the number of lines that you write. In the long run, however, it will likely save you time because you will always know what session states are available to you in your application. No more trying to remember what you named it 6 months ago when you are asked to make a change to the application.

I’ve used this technique in a number of projects, and it has worked well. Thanks to Paul Sheriff for sharing this tip when presenting at the Iowa Dot Net Users Group.