Why I think Scott Guthrie Recommends or Recommended ASP.NET Code-Beside Designs

The picture at left is a picture of the .NET Framework. It’s a folder full of ‘stuff’ on your hard drive. In fact, it’s the old version of the .NET Framework (the latest release is in another folder, sitting right next to the one shown). I show this folder to remind myself of when I started living with the .NET Framework: the create date shows Monday, March 11 2002, 9:36:40 pm. So over three years is my time with the .NET Framework. (We can subtract about six months from the three years because after it was installed back in 2002 it just sat there being ignored by me.) By the way, one could argue that the 1.1 version of the .NET Framework is the ‘useable’ version of the Framework and this did not appear on my primary development machine until 4/10/2003.

Let’s confine ourselves to about two years of me actively implementing my ‘personal’ technology plan to divest from VB6/ASP, COM-based ‘linear prose’ (spaghetti) and move into the ‘abstract-morphic’ world of the .NET Framework. The technology plan in bullets:

• Define representations of physical data stores in the abstract world of the .NET Framework. Achievement here is discussed in “Founding the Songhay.Data.Components Namespace.” Nothing moves in my world of publishing without a data management framework. So obtaining these definitions is essential and fundamental. There was not much ‘divestment’ here: the SQL Server stored procedures built back in my ASP days are still useful (although I do wish that .NET SQL Data adapters could easily ‘see’ multiple data sets in one stored procedure at design time in Visual Studio .NET).
• Develop Web services to increase the surface area of data access. Every time I attempt to work here, I discover that another fundamental data representation problem has to be addressed. Web service stuff is still new stuff—so not much here. I’m not building from scratch kids; I’m trying to drag along mountains of legacy data and legacy procedures with me.
• *Develop human-*readable “smart” (and thin) clients that consume end points of data access. I have already said that Windows Forms 1.x suck (—nevertheless, I use them). So this is where Scott Guthrie and ASP.NET code-beside designs emerge in relevance.

My recent ASP.NET epiphanies finally reveal to me why ASP.NET 2.0 added or removed (based on the Beta you are fruggin with) the code-beside model to its design. But let me be clear about what I mean by “code-beside” patterns. I mean creating an ASPX page and loading it up with Web form controls and script blocks running at the server. These script blocks sit beside the controls—hence code beside… (No dependencies on partial classes here.) This is nothing new: the tutorials on asp.net have been using this pattern from the beginning. Why am I so late to the party? Because the current RTM version of Visual Studio .NET is almost entirely ignorant of this pattern. You have to work against Visual Studio .NET to build code-beside pages (which, to me, is why The ASP.NET Web Matrix Project has been so popular). Now that years of writing C# and VB.NET code under the tutelage of IntelliSense™ have gone by, I can break the fetters and drop small blocks of code directly into script blocks. I stress the word “small” because:

When you are writing ASP.NET pages that require inheritance and hundreds of lines of code you are probably on the DotNetNuke.com portal team or you are cramming code into your client that should be in another layer of your application (like a “business rules” or data access layer).

• You might not be taking advantage of pre-compiling complex, user-interface experiences into custom server controls.
• You might not be using XSL templates with the Xml Web Server Control to declare complex, user-interface experiences.
• You might not be taking advantage of running “traditional” HTML tags at the server (like the HTML title element) and processing them in code as HtmlGenericControl objects.

When you can redesign your code-behind ASP.NET pages such that almost all of the code resides in the Page_Load() event procedure, you are probably wasting your time (like I have been doing for at least a year) trying to define a formal namespace and class name for these pages and compiling it into a DLL. I would prefer to throw it all in ASPX files that compile dynamically and treat it like my ASP files I hate so much. The opinion here is and will be vindicated by the following:

• The ASP.NET team will not discourage using dynamic compilation and will address concerns with performance (starting with caching).
• The ASP.NET team will continue to tout its zero-lines-of-code (ZLOC) design goal and ‘accidentally’ do the work the SharePoint portal team has been struggling with for years (before the SharePoint team, the FrontPage team still writhes in anguish).
• I’m almost sure that the next release of Visual Studio .NET no longer ‘forces’ developers to define projects that compile a DLL—along with no longer being forced to associate Web forms projects with IIS.
• The presence of IntelliSense™ in ASPX-page script blocks in the next release of ASP.NET will encourage us to use this kind of “code-beside” pattern.

Scott Guthrie produced a motion picture Web cast at Microsoft showing off ASP.NET in the future release of Visual Studio.

rasx()