Archive for the ‘.NET’ Category

Server-Side Validation

A couple of weeks ago, I was talking to someone who is doing a project for us. He is fairly new to .NET programming, so when I told him that I wanted both server-side and client-side validation, it scared him a little bit.

He knew how to do client-side validation using the built-in validation controls in ASP.NET. This is fairly easy to do. You put the validation control into your aspx file, and connect it to the control you want to validate. Then ASP.NET will include the required JavaScript for the client to do validation. The problem is that this JavaScript doesn’t run if the client has JavaScript turned off, or if the client doesn’t support JavaScript.

He thought he’d have to write the code to do the server-side validation. He wasn’t aware that you could use .NET’s validation controls on the server-side as well as client-side. All you need to do is add the following code to the beginning of your button handler:

if (!Page.IsValid)
{
    return;
}

This cause the server-side to run through the validation controls. If any fail, then you return to web page, which will now include the error messages from your validation controls. If all the validation controls pass, then it will go on to the next line in the button handler.

It really is this easy to include server-side validation in ASP.NET!

Advertisements

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:

MySettings.calendarConnectionString
MySettings.mailFrom

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.