Code Organization

Chapter 9 - Data-Driven ASP.NET Applications in the Real World
byJohn Kauffman, Fabio Claudio Ferracchiatiet al.?
Wrox Press ?2002

To this point in the book, we've been putting our Visual Basic .NET code in the same ASPX pages as the ASP.NET controls and HTML code that display the information we retrieve from the database. While this technique certainly works, there are advantages to maintaining clear separation between these two entities. In this section, we'll explain what those advantages are, and how to write code that capitalizes on them.

Benefits of Code Separation

There are several good reasons for keeping your page layout separate from the rest of your code. Let's look at them in detail:

1. The IDE is more user-friendly.

When you use Visual Studio .NET to place your Visual Basic .NET code in separate files (called code-behind files), the development experience is richer. You get features such as IntelliSense, improved debugging capabilities, and better compiler functionality (VB.NET's compiler runs behind the scenes as you write code, and flags any compile-time errors with a blue line).

2. Separation allows layout to be modified without recompiling code.

Keeping your page layout separate from your code allows you to change the look and feel of your pages without having to recompile. This is because of the way ASP.NET can handle ASPX pages. All the VB.NET classes within your application are compiled into a DLL when you build your web project. However, the content of the ASPX page is not compiled until the page is accessed for the first time. Each time the page changes, it is simply recompiled again, which means that you can change the ASPX page without changing the underlying code. If you wanted to change the width of a table, or the background of the page, or anything else within your page layout, you can do it without having to recompile your VB.NET event handlers.

Of course, there are limitations. If you add server controls to the page layout, they won't be recognized within the application, because the application was compiled before the server control existed. If, on the other hand, you delete a server control from the page, and yet the code tries to reference it, you'll get errors. The rule of thumb is that it's fine to change your HTML, and even the positioning or stylistic aspects of server controls, but be cautious when adding and removing elements. If in doubt, rebuild the entire project anyway.

3. Designers can focus on the look and feel, while the coder focuses on the functionality.

There are some coders who are also good at designing the look and feel of an application. For the rest of us, there are professional web designers to do that job. If you've worked in the old ASP model, and you let designers modify your ASP pages, you've probably been frustrated more than once when they've accidentally made changes to the code and broken the page. In ASP.NET, since no code needs to exist in your page layout file, they can make the changes they need to make without worry. They'll be able to focus on the page, not the code. Another key benefit is that the designer and the coder don't have to worry about stepping on each other's toes when they need to make changes at the same time. The page layout and code are in separate files, so they can both have the files they need open in their workspace, without having to worry about overwriting each other's changes.

4. Your code won't be accessible on a production server.

If you resell your application, or have a lot of proprietary business logic in it, you don't want it to be accessible to end users. With .NET, you only have to deploy the ASPX pages and the single DLL that's created when you compile your application. You don't have to place the code files themselves on your production server. Again, if you've worked in the old ASP world for any length of time, you've no doubt heard about various hacks that allowed the contents of the ASP pages to be viewed over the Internet. This should never be a problem again.

Try It Out - Separating Your Page Layout from Your Code

The beauty of using Visual Studio .NET is that it takes care of setting up the separation of your page layout and code automatically. Still, it's important to understand what it's doing behind the scenes. Let's create an ASP.NET web application in Visual Basic .NET and explain what's going on.

1. Go to the Visual Studio's File | New Project menu, choose Visual Basic Projects, and opt to create an ASP.NET Web Application called CodeSep.

2. When VS.NET finishes its machinations, you'll see the following display. Our ASP.NET page is called WebForm1.aspx, and by default we see the design view for that page:

   

How It Works

You can alternate the page layout between the design view and the HTML view by clicking on either Design or HTML at the bottom of the screen. Here's what you'll see in the HTML view:

The @Page directive at the top of the page is what makes it all work. Let's look at the attributes used, noting as we do so that this list is by no means exhaustive. Refer to the documentation for a complete reference.

Attribute	Description
Language	If you use inline code (code within <% and %> blocks), this is the language used. This ensures that the correct compiler is called for this inline code.
AutoEventWireup	This attribute determines whether or not events that take place on the client cause the associated event handlers within the application to execute on the server side automatically. If set to true, which is the default, an event on the client causes the application to look for an event handler with a specific name, which is based on the name of the control raising the event and the type of event. If this event handler is found, it's executed. If set to false, you must use the Handles keyword within your code to associate a handler with an event.
CodeBehind	This is for Visual Studio .NET's benefit. It uses this to know what physical file the code for this page resides in.
Inherits	When using code-behind, this represents the class that the page itself will derive from.

Having examined these attributes, you might be wondering why you don't see a file named WebForm1.aspx.vb in the Solution Explorer. This is because Visual Studio .NET tries to make the environment more 'friendly' by hiding the code-behind pages! To see them, click on the Show all files icon in the Solution Explorer window. You'll now see the following:

To see the WebForm1.aspx.vb file, expand the + sign to the left of the WebForm1.aspx file. You'll see the WebForm1.aspx.vb file where all the code is kept for your page.

Let's take a look at the code now. Visual Studio .NET gives you several ways to access the code without having to click the Show all files icon. You can right-click on the page in the Solution Explorer and click View Code, you can right-click on the page in HTML view and choose View Code, or you can just press F7 when on the page. However you get there, though, this is the code:

    Public Class WebForm1        Inherits System.Web.UI.Page    #Region " Web Form Designer Generated Code "        'This call is required by the Web Form Designer.        <System.Diagnostics.DebuggerStepThrough()> Private Sub InitializeComponent()        End Sub        Private Sub Page_Init(ByVal sender As System.Object, _                              ByVal e As System.EventArgs) Handles MyBase.Init            'CODEGEN: This method call is required by the Web Form Designer            'Do not modify it using the code editor.            InitializeComponent()        End Sub    #End Region           Private Sub Page_Load(ByVal sender As System.Object, _                                 ByVal e As System.EventArgs) Handles MyBase.Load                'Put user code to initialize the page here           End Sub       End Class 

There are several key things to understand about the default code created by Visual Studio .NET:

1. The fully qualified class name is the same as that specified in the @Page Inherits attribute. In this example, the fully qualified class name is CodeSep.WebForm1. You only see the name as WebForm1 here because the namespace CodeSep is specified within the project's properties.

   If you rename the ASPX page, the code-behind file will be renamed as well. However, the class itself won't be renamed. In most cases you'll be fine, because the ASPX page still references the correct class through the @Page Inherits attribute. However, it's good programming practice to name your code-behind web form classes the same as the file in which they're located.

2. All web forms derive from System.Web.UI.Page, or a class that inherits from it.

3. A special code region called Web Form Designer Generated Code is created. This allows the Visual Studio .NET designer to interact with the page. As the comment mentions, you should never change this code. However, there will be times where you may need to add code to the Page_Init subroutine.

When developing professional applications, take advantage of the benefits of page layout and code separation. It may seem more complicated at first, but after you get used to it, you'll be glad you did. In the remaining chapters of this book, we'll be using Visual Studio .NET's facilities to enhance our coding efforts.