Build Your Own ASP.NET Website Using C# and VB.NET. Pt. 3. | WebReference

Build Your Own ASP.NET Website Using C# and VB.NET. Pt. 3.

Build Your Own ASP.NET Website Using C# and VB.NET. Pt. 3.

Reproduced from "Build Your Own ASP.NET Website Using C# & VB.NET" by permission of SitePoint. ISBN 0-9579218-6-1 , copyright 2004. All rights reserved. See for more information.

Table of Contents

Programming Basics
Control Events and Subroutines
Page Events
Variables and Variable Declaration
Conditional Logic
Understanding Namespaces
Object Oriented Programming Concepts
Understanding Inheritance
Separating Code From Content With Code-Behind

As you learned at the end of the last chapter, one of the great things about ASP.NET is that we can pick and choose which of the various .NET languages we like. In this chapter, we’ll look at some key programming principles using our two chosen languages, VB.NET and C#. We’ll start off with a run-down of some basic programming concepts as they relate to ASP.NET using both languages. We’ll introduce programming fundamentals such as control and page events, variables, arrays, functions, operators, conditionals, and loops. Next, we’ll dive into namespaces and address the topic of classes—how they’re exposed through namespaces, and which you’ll use most often.

The final sections of the chapter cover some of the ideas underlying modern, effective ASP.NET design, starting with that of code-behind and the value it provides by helping us separate code from presentation. We finish with an examination of how object-oriented programming techniques impact the ASP.NET developer.

Programming Basics

One of the building blocks of an ASP.NET page is the application logic: the actual programming code that allows the page to function. To get anywhere with this, you need to grasp the concept of events. All ASP.NET pages will contain controls, such as text boxes, check boxes, lists, and more, each of these controls allowing the user to interact with it in some way. Check boxes can be checked, lists can be scrolled, items on them selected, and so on. Now, whenever one of these actions is performed, the control will raise an event. It is by handling these events with code that we get our ASP.NET pages to do what we want.

For instance, say a user clicks a button on an ASP.NET page. That button (or, strictly, the ASP.NET Button control) raises an event (in this case it will be the Click event). When the ASP.NET runtime registers this event, it calls any code we have written to handle it. We would use this code to perform whatever action that button was supposed to perform, for instance, to save form data to a file, or retrieve requested information from a database. Events really are key to ASP.NET programming, which is why we’ll start by taking a closer look at them. Then, there’s the messy business of writing the actual handler code, which means we need to check out some common programming techniques in the next sections. Specifically, we’re going to cover the following areas:

It wouldn’t be practical, or even necessary, to cover all aspects of VB.NET and C# in this book, so we’re going to cover enough to get you started, completing the projects and samples using both languages. Moreover, I’d say that the programming concepts you’ll learn here will be more than adequate to complete the great majority of day-to-day Web development tasks using ASP.NET.

As I just mentioned, an event (sometimes more than one) is raised, and handler code is called, in response to a specific action on a particular control. For instance, the code below creates a server-side button and label. Note the use of the OnClick attribute on the Button control:

When the button is clicked, it raises the Click event, and ASP.NET checks the OnClick attribute to find the name of the handler subroutine for that event. Here, we tell ASP.NET to call the btn1_Click() routine. So now we have to write this subroutine, which we would normally place within a code declaration block inside the <head> tag, like this:

This code simply sets a message to display on the label that we also declared with the button. So, when this page is run and users click the button, they’ll see the message "Hello World" appear next to it.

I hope you can now start to come to grips with the idea of control events and how they’re used to call particular subroutines. In fact, there are many events that your controls can use, some of which are only found on certain controls—not others. Here’s the complete set of attributes the Button control supports for handling events:


As we’ve seen, the subroutine indicated by this attribute is called for the Click event, which occurs when the user clicks the button.


As with OnClick, the subroutine indicated by this attribute is called when the button is clicked.


The subroutine indicated by this attribute is called when the button is loaded for the first time—generally when the page first loads.


When the button is initialized, any subroutine given in this attribute will be called.


We can run code just before the button is rendered, using this attribute.


This subroutine will run when the control is unloaded from memory—basically, when the user goes to a different page or closes the browser entirely.


This occurs when the button is released from memory.


This fires when the button is bound to a data source.

Don’t worry too much about the intricacies of all these events and when they happen; I just want you to understand that a single control can produce a number of different events. In the case of the Button control, you’ll almost always be interested in the Click event, as the others are only useful in rather obscure circumstances.

When a control raises an event, the specified subroutine (if there is one) is executed. Let’s now take a look at the structure of a typical subroutine that interacts with a Web control:

Public Sub mySubName(s As Object, e As EventArgs)
  ' Write your code here
End Sub
public void mySubName(Object s, EventArgs e) {
  // Write your code here

Let’s break down all the components that make up a typical subroutine:

Public, public

Defines the scope of the subroutine. There are a few different options to choose from, the most frequently used being Public (for a global subroutine that can be used anywhere within the entire page) and Private (for subroutines that are available for the specific class only). If you don’t yet understand the difference, your best bet is to stick with Public for now.

Sub, void

Defines the chunk of code as a subroutine. A subroutine is a named block of code that doesn’t return a result; thus, in C#, we use the void keyword, which means exactly that. We don’t need this in VB.NET, because the Sub keyword already implies that no value is returned.


This part gives the name we’ve chosen for the subroutine.

s As Object, Object s

When we write a subroutine that will function as an event handler, it must accept two parameters. The first is the control that generated the event, which is an Object. Here, we are putting that Object in a variable named s (more on variables later in this chapter). We can then access features and settings of the specific control from our subroutine using the variable.

e As EventArgs, EventArgs e

The second parameter contains certain information specific to the event that was raised. Note that, in many cases, you won’t need to use either of these two parameters, so you don’t need to worry about them too much at this stage.

As this chapter progresses, you’ll see how subroutines associated with particular events by the appropriate attributes on controls can revolutionize the way your user interacts with your application.

Created: March 27, 2003
Revised: July 5, 2004