CodeToad - Fast Track ASP.Net Part 2 : Why a New Version?

For many classic ASP programmers, the change to ASP.NET poses a major paradigm shift in the development of web applications. Classic ASP is an excellent tool for developing web applications using Microsoft technologies. However, as with most development models, ASP contained some fundamental design problems that resulted in many more developmental issues.

Spaghetti Code

If you've created many applications with ASP, you'll be familiar with long pages that contained server-side script code intermingled with HTML. Often, these pages would switch back and forth between ASP and HTML/Client Script many times within one particular page. The result is that the ASP ISAPI filter running on all IIS servers was required to switch on and off numerous times in a single response to accommodate all of the server code.

Take the following example, in which we fill up an HTML drop-down menu with results from a database query:

Set dbConn = Server.CreateObject("ADODB.Connection")

Set rs = Server.CreateObject("ADODB.Recordset")

dbConn.Open "Provider=SQLOLEDB.1;UID=sa;PWD=pass4Sql;Server=bglaptop;Initial Catalog=pubs"

rs.Open "SELECT * FROM Authors",dbConn,3,3

do while not rs.EOF

rs.movenext

loop

</select>

That's 16 lines of code for something that generates one simple HTML control. This method of coding can diminish application performance because the scripting engine running on the server must switch between script and HTML code. If the Response.Buffer property has not been turned on for an ASP page that sends numerous messages to the client browser in this way, numerous small packets will be sent to the client browser, resulting in slower performance.

For more information on optimizing ASP applications, take a look at the MSDN article entitled "25+ ASP Tips to Improve Performance and Style," located on the Microsoft MSDN site at http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnasp/html/asptips.asp.

Now consider if the graphic designers on your web development team needed to come back and make a few changes in one of their WYSIWYG editors. Hopefully, you kept a few spare copies of this code around just in case. Most HTML editors fail to recognize ASP code, and thus end up removing the server-side code entirely.

Code written with these constructs can easily grow to unmanageable heights. Add to the puzzle the possibility that COM objects are created to be used in conjunction with ASP scripts and the management nightmare grows, as management staff must interpret what happens in components that create functionality for the complex ASP scripts. ASP.NET pages are written with traditional object orientation in mind, so the pages themselves contain controls that can be programmed against similarly to desktop applications. This removes the dependence of the traditional HTML markup and inline code combination, thus minimizing the "spaghetti effect." If you opt to use the code-behind approach, the programmatic logic and presentation are actually separated into two different files, thus removing the requirement of maintaining everything in one place. Of course, no programming platform will ever remove the responsibility of having to maintain and possibly augment existing applications, but by using ASP.NET in place of ASP or another scripted counterpart the time it takes to determine problems can be greatly minimized.

Whether you intermingle your server and client code or choose to have the server regurgitate all of it for you on the fly, ASP code tended to become beastly, long, and incredibly difficult to debug (even if you did get ASP debugging working in your environment!).

ASP is Nothing More than Script

At the time of its creation, ASP was the answer to many web developers' woes. Rather than require the learning of a completely new language or methodology, developers had the chance of taking familiar languages – VBScript and JavaScript – and using them in a server-based programming paradigm. By using the already-popular COM programming model as a backbone, these scripting languages served as a new vehicle for access to server components and resources.

Although ASP was an easy concept to grasp for many developers who were already deft in the usage of these scripting languages, this very fact contributed to its slow processing speed. The ASP scripts need to be interpreted in a scripting engine and transposed into HTML via a server-side ISAPI filter, so extra layers of processing were required to generate the HTML that was eventually exposed to browsing clients.

Performance wasn't the only problem. Every object or variable created for use in classic ASP script was created with a variant data type. As most Visual Basic programmers know, variant data types require larger amounts of memory and result in much slower execution times. Additionally, repeated attempts to develop a truly integrated IDE that provided ASP programmers with better debugging capabilities never produced anything comparable to the powerful debugging tools found in Visual Basic and Visual C++. Without debugging tools, ASP programmers were hard-pressed to troubleshoot the problems in their scripts.

These problems have been circumvented in ASP.NET. For starters, ASP.NET pages and web services are executed within the CLR (Common Language Runtime), so they can be authored in any language for which there is a CLR-compliant compiler. No longer are you limited to the use of VBScript or JavaScript. What's important to note about this fact is that ASP.NET pages are not interpreted, but rather compiled into .NET assemblies. This is most likely the biggest change – and enhancement – to Microsoft's web development model. What actually happens behind the scenes is rather revolutionary. Though an ASPX file exists on the web server in a virtual directory, the whole application itself is actually compiled into executable programs at build time. Each ASPX page, class, and web service becomes a part of the assembly created by the program compilation. If any of the ASPX or ASMX files are modified following the compilation, it is recompiled – on the fly – the next time a client attempts to browse or access it. In essence, ASP.NET applications are smart enough, due to their integration into the CLR and .NET Framework, to know when they need to be recompiled and do so before execution.

Microsoft's New Idea and the Death of COM

At the 2001 DevelopMentor .NET conference in San Francisco, a few presenters joked that .NET would eventually be "the death of COM." Dave Chappel, one of the keynote speakers at the conference, began his speech with a series of rules he claimed "must be adopted for a successful migration to .NET (or any new developmental framework)". Early one morning during the conference, Mr. Chappel proclaimed that programmers "must always reset their defaults". A particular textbook that was written to introduce programmers to the C# language, in discussing the concepts of managed and unmanaged code in terms of the .NET framework, refers to COM as "old and archaic technology".

These less-than-subtle clues to Microsoft's new strategy indicate a very important paradigm shift in its model for distributed enterprise development. Though Microsoft claims undying support for COM and COM+, it's obvious that .NET is being touted as the "new way" for developers. As COM applications wane in popularity and applications become converted to .NET, classic ASP shall become a thing of the past. ASP relies on COM and late binding methodology to access server-based objects and resources. Errata abound that illustrate COM and .NET interoperability, but the sad fact is simple; classic ASP applications have no place in a .NET world.

Microsoft would never abandon its millions of dedicated web developers, so in keeping with the Chappelian idea of default resetting, a new breed of web application was introduced to us in .NET. ASP.NET introduces a whole new breed of more robust, scalable, and efficient web-based applications. By using compiled (rather than interpreted) code, data-bound controls that work in an extensible framework, and a hierarchical collection of objects accessible by virtually any language (provided a CLR-compliant compiler exist for that language), this new framework promises a new breadth of functionality, performance, and scalability.