In ASP.NET 1.x, you have two ways to write the code for a web page. With the first option, you insert all the code in the .aspx file within a <script> block marked with the runat="server" attribute. The second option uses the code-behind model, in which markup and code go in separate files. For backward compatibility, both models are fully supported in Version 2.0. The code-behind model, though, has been significantly improved; some earlier documentation refers to it with a new name-the code-beside model.

Inline code is not exactly a best practice, though I'll be the first to say that in some situations it can be more practical than other techniques. Inline code doesn't make the page run slower, nor does it affect critical parameters of a site such as throughput and scalability. Nothing bad can happen to your application if you use inline code. However, real-world pages need a good amount of server code, and appending all that code to the <script> tag of the .aspx file makes the file significantly hard to read, edit, and maintain.

Visual Studio .NET 2003 doesn't support inline code. If you try to use it anyway, be prepared to lose some features such as IntelliSense support.

Code-behind is based on the idea that each Web Forms page is bound to a separate class file. This class ends up being the basis of the dynamically generated page class that the ASP.NET runtime creates for each requested .aspx resource. All the server code you need to associate to the .aspx resource flows into the code-behind class. This is neat and elegant in theory, but in the Visual Studio .NET 2003 implementation it suffers from a few drawbacks. It requires an explicit compile step to deploy or run and the AppDomain that hosts the application is restarted on every change.

In ASP.NET 2.0, the enhanced code-behind model takes advantage of a new language feature known as "partial classes. As the name suggests, a partial class is a class that doesn't contain the full class definition. In this way, the source of the class can be sparse and occupy more files. This general-purpose feature finds an immediate application in ASP.NET.

In the new code-behind model, the Visual Studio .NET 2005 generated class file for a page is not a complete class definition. It includes only the application code you need-typically, event handlers. Instance variables and explicit event binding code is inferred from the markup and added at compile-time care of the ASP.NET runtime. The new syntax is similar to that of version 1.x, although it makes use of a different set of keywords. Here's an example:

<%@ page Language="C#" CompileWith="HelloBeside.aspx.cs" 
         ClassName="ASP.HelloBeside_aspx" %>

The page is compiled to a dynamic class that inherits from Page and is a partial class that results from the merge of the code added through Visual Studio .NET 2005 and the glue code inferred from the markup. In ASP.NET 1.x, the dynamically created page class inherits from the code-behind class. For this reason, the code-behind class has to be a fully defined class; this fact forces Visual Studio .NET 2003 to insert designer-specific code in hidden regions.

The partial class mechanism avoids designer-specific code in the class files created. The new model is simpler and lets you include controls on a page without having to explicitly create instance variables for them in the code-behind class. As a result, the code-behind page will never be out of sync with the controls declared in the markup.

Dino Esposito is Wintellect's ADO.NET and XML expert, and a trainer and consultant based in Rome, Italy. Dino is a contributing editor to Windows Developer Network and MSDN Magazine, and the author of several books for Microsoft Press including Building Web Solutions with ASP.NET and ADO.NET and Applied XML Programming for .NET. Contact Dino at [email protected].