Introduction

Welcome to an introduction of the essentials of ASP.NET. This tutorial will guide you into the changes from ASP to ASP.NET, what this Page object model is all about, and will show you how to work with controls. This tutorial is meant to be a step-by-step tutorial, and will guide you through the process of the examples, which can be downloaded from this tutorial. In addition, the examples for this project were created with Visual Web Developer, which at the time of writing was a free tool downloadable off of Microsoft’s web site.

So, what are the differences between ASP and ASP.NET? When you created an ASP page, you created content using <% %>tags, which processed server-based rendering of content dynamically when the page ran on the server. This was satisfactory to run on the server; however, it was very limited and redundant in its approach. The more conditionals available meant the more code you created, which could amount to enormously-sized ASP pages. However, with the advent of ASP.NET, all of this changes. Now, you have the capabilities to separate your HTML design and your code logic. You can also work with components a lot easier, and managed code provides a safer way to work. Not only that, avoiding the registering/unregistering process of COM components is the biggest benefit in my opinion.

Inline Model

You can’t help but notice that the approach has changed drastically from ASP to ASP.NET. Let’s take a look at an ASP.NET page. The following is an example of a page that has inline code. In the downloaded web project, it is the file called inlinepage.aspx:

There are few points to talk about in this code sample. First, we still see the <% %>notation as in ASP; however, these are for more limited situations. For instance, the first statement in the page is the <%@ Page %>directive. This page directive is a special directive that sets up the specifics of the page. For instance, the Language attribute states that any server-based code has to be C#. What I mean by server-based code is any code that is between the <script runat="server"></script> tags. Defining these tags with the runat=”server” attribute denotes that they can be used to store code for specific .NET objects and their events. Don’t worry about this now; I will make sure I explain this in-depth in the near future. Getting back to the Page element, other attributes can be defined. For instance, whenever you define a ClassName attribute, this specifies that the class name of this page is PageIntro.InlinePage. Remember that .NET is object-oriented, and as such, pages can be defined in namespaces, creating a hierarchy.

Code-Behind Model

A code-behind page, however, separates the code logic from the HTML design. For instance, all of the code in the previous example’s tags is defined in a CS or VB file. This is the code-behind file in the target language (CS for C# and VB for VB.NET). For example, the file default.aspx would have a code-behind file named default.aspx.cs. I will show how these files are linked together in a moment. But for now, the code-behind file contains all of the control event handlers, as well as other methods, properties, and events defined in the page class. The two files look like this:

Code-Behind Model ASPX

Code-Behind Model Code

As you can see, the two are noticeably different. For instance, you notice there are additional properties used in the @Page directive above. Remember the @Page directive contains important settings for the page, which it links to the code-behind CS file through the CodeFile attribute, and specifies the name of the class through the Inherits property. The inherits property is used to declare the class name to compile the page with, so that all of the event handler declarations and other objects are linked with that page. Notice that we have a label control, which the page load event handler (more on these events later) has property assignments for the label control. Because the code-behind file is linked with the page, it automatically knows which objects exist on the page that have runat=”server” defined. Because of this, the code-behind page already knows about the label.

Also, in the inline model, we had an @Imports statement, to include certain namespaces in the page. In the code-behind model, any namespaces used in the page are defined with “using” statements that appear at the very top (in VB.NET, Imports is used instead of using). These statements allow shortcuts to the full class names. For instance, the Color structure is defined in the System.Drawing namespace. Without using this namespace, the full name must be System.Drawing.Color.Navy, instead of the above short-hand notation.

Page Events/Lifecycle

I was referencing the Page_Load event handler above; what was that all about? In ASP.NET, think of everything as an object; objects have methods, events, and properties. This is true for an ASP.NET page; an ASP.NET page has events, methods and properties. Some of the most key events are the Init event, which occurs upon Page initialization; the Load event, which occurs when the page is loading (the most common event used for typical page processing); the PreRender event, which occurs near the end of the page lifecycle, before the page is loaded; and the Unload event, which occurs at the end when the page processing completes, and the page objects are destroyed. You can find a more detailed resource about the Page lifecycle events at: http://msdn2.microsoft.com/en-us/library/ms178472.aspx. These events can be used to tap into and do whatever you need to do in your application. Most commonly, these event handlers are used to change the property values of a control in the page. Next, we will look at server controls and how they operate.

Summary

The page lifecycle is a somewhat complex, but rather useful, architecture for creating ASP.NET pages. It contains several events to tap into with your ASP.NET controls (as we will see in the next tutorial) using either the inline or code-behind model.

References

You can read more about the page lifecycle at: http://msdn2.microsoft.com/en-us/library/ms178472.aspx

Part 2

Read part 2: Introduction to ASP.NET Development, Part 2 - Server Controls

About Brian Mains

Brian Mains is an application developer consultant with Computer Aid Inc. He formerly worked with the Department of Public Welfare. In both places of business, he developed both windows and web applications, small and large, using the latest .NET technologies. In addition, he had spent many hou... This author has published 73 articles on DotNetSlackers. View other articles or the complete profile here.