ASP.NET v2.0: Code-Beside Replaces Code-Behind

ASP.NET v2.0: Code-Beside Replaces Code-Behind

Paul Wilson
www.WilsonDotNet.com
www.ASPAlliance.com/PaulWilson

Previous Article            .NET v2.0 (Whidbey) Roadmap            Next Article

Overview

ASP.NET v2.0 replaces the Code-Behind code-separation technique with Code-Beside, which is designed to be an easier and less brittle method based on Partial Types. Code-Behind is based on the ASPX Page, with all the declarative html and controls, inheriting from another class -- which was excellent OO, but awkward in practice. Why was it awkward? All the controls had to be declared again, but not initialized, as protected fields in order to actually code against them in the various events.

Introducing Code-Beside

Code-Beside is based on a new construct in v2.0 of the .NET Framework, called Partial Types, which allows one class to be defined in multiple source files. This concept may sound very weird at first, but its very similar to what already exists in languages like C++ with its header files and Delphi with its form files. The main intended use for Partial Types is to allow code generators to create a class that can be extended in a separate file to not mess up any re-generation. The ASP.NET team decided to use this feature in v2.0 to improve code-separation, so now the ASPX declarative Page and the associated code file are the same class.

Code-Beside Syntax

The ASPX declarative Page should still start with the usual Page directive, but the main attributes used for Code-Beside are now compilewith and classname, instead of the former Code-Behind attributes codebehind (or src) and inherits:

<% Page compilewith="MyPage.aspx.vb" classname="MyNamespace.MyClassName" %>

The compilewith attribute is required -- without it the code file is not compiled. The classname attribute is optional if there is no namespace used for the class and if the class name is the default aspx class name, something like MyPage_aspx. The class declaration must include the Expands keyword for VB, or partial for C#:

VB: Public Expands Class MyClassName
C#: public partial class MyClassName

Code-Beside Details

The rest of the code file, the Code-Beside Partial Class, is now much simpler. There are no longer any declarations of controls that need to be made in the code, which also finally makes it easy to have code-separation without Visual Studio. There are also no event declarations required, since control events can be declared with the control declaration in the ASPX Page, and page events are auto wired now. Basically, the code file is now identical to the equivalent in-line code, which makes the choice between in-line and Code-Beside simply about code-separation -- even more important when you realize that in-line code gets full intellisense.

Code-Behind Support

VS.NET Whidbey automatically migrates Code-Behind to the new Code-Beside method. You can continue to use a base Page class by using the inherits attribute in the Page directive, although oddly enough you cannot specify inheritance in the code. You can also continue to use the src attribute, along with the inherits attribute, if you want to continue using Code-Behind instead of the new Code-Beside method. On the other hand, the codebehind attribute is no longer supported at all, but it was actually only a VS.NET attribute, so you can continue to get the same behavior using the inherits attribute if you compile the code files separately.

Conclusion

ASP.NET v2.0 makes code-separation easier than the original Code-Behind method by introducing Code-Beside, which is based on the new Partial Type construct. While it may be argued that it is no longer a pure object-oriented technique, it is now much simpler to implement, regardless of developer skill level or tool used. It is also much less brittle to maintain, since the original Code-Behind method had the various declarations sometimes get out of sync when the page or code was edited.

Version Note

This article was based on an early Alpha release of ASP.NET v2.0 and VS.NET Whidbey. It is possible that some implementation or v1.* compatibility details will change.

Author Bio

Paul Wilson is a software architect in Atlanta, currently with PRG-Schultz. He specializes in Microsoft technologies, including .NET, C#, ASP, SQL, COM+, and VB. His WilsonWebForm Control allows Multiple Forms and Non-PostBack Forms in ASP.NET. He is a Microsoft MVP in ASP.NET and is also recognized as an ASPInsider. He is a moderator on Microsoft's ASP.NET Forums, as well as one of the top posters. He is holds the MCSD, MCAD, MCDBA, and MCSE certifications. Please visit his website, www.WilsonDotNet.com, or email him at Paul@WilsonDotNet.com.