By Tim Landgrave

I know from experience that you can get a 50 to 80 percent performance benefit just from moving a user interface (UI) from ASP to ASP.NET. You can attribute about half of this performance increase to the simple fact that in most well-crafted applications, the only portion of the application that’s not natively compiled is the UI. The business and data tier components are already compiled DLLs that the UI calls through a COM interface. Since the .NET Framework provides excellent interoperability with existing COM objects, it’s logical to consider porting just the ASP-based UI layer of an application over to ASP.NET.

But there are several other benefits to doing this beyond compilation and COM interoperability. Let’s look at them.

The ASP.NET UI model
After struggling with the editing combination of Visual Notepad and Visual Interdev, most developers who look at the ASP.NET interface are immediately impressed by the improvements in the ASP.NET model for building a UI. Microsoft has allowed companies to greatly reduce the time required for UI development by implementing a new page and control model that closely mimics the development paradigm of VB6. The page model simulates the Windows messaging model and splits it between the Web client and the Web server. More important, ASP.NET Server controls give developers VB6-like forms capability to automatically manage the required state without developer intervention. The end result is a much shorter development time for creating much more robust UIs.

ASP.NET also ships with a wide variety of prewritten controls—in addition to providing the framework to host them—including a TextBox, Calendar, Drop-down List Box, TreeView, TabControl, and many others. These server controls provide functionality similar to ActiveX controls, but they don’t require the same level of client configuration or permission. Instead of executing binary code on the client, they execute on the server and generate either HTML output consumable by the client browser or, if supported by the browser, a combination of HTML and JScript that allows forms to be executed client side to minimize the number of round-trips associated with Web applications.

Upgrading existing ASP forms to ASP.NET requires loading the HTML code into a new ASP.NET form and then changing the controls to server controls by manipulating the HTML source. If you have a lot of scripting code in the form and have made use of Visual Interdev designers, you’ll find it easier to run the ASP application and then cut and paste the HTML from the View Source option in the browser to get the basic form into ASP.NET.

UI model is extensible
To realize the real benefits of ASP.NET, you won’t just copy HTML code from an existing ASP application. You’ll take advantage of ASP.NET code reuse by defining page elements as reusable controls. The extensibility of the ASP.NET UI model allows you to replace ASP pages by grouping common functionality and implementing new ASP.NET pages with a combination of a new base page class, user controls, and Web Server controls. For example, one of the most frustrating things that corporate users deal with is the myriad UI models they face when using ASP applications from different groups in the organization.

One of the first recommendations we make to companies moving to ASP.NET is that they replace homegrown menu and navigation systems with either an internal ASP.NET implementation of page classes and user controls or with a standard third-party component vendor’s navigation implementation.

If you choose a third-party vendor’s navigation system, make sure you select one that gives you the .NET source code so that you can create your own internal navigation standard. By reusing this mechanism across all of your ASP.NET systems, your users will have a common navigation paradigm, and you’ll greatly reduce the amount of navigation code you have to write for future systems.

Other key areas to consider for UI migration benefits
Beyond the benefits of the UI development model, you should also make extensive use of the caching and session state mechanisms built into ASP.NET. With very little work from your developers, you can use the ASP.NET output caching mechanisms to dramatically increase page load performance for your users. If you need to cache individual objects or have finer-grained control over page-caching mechanisms, you can use the built-in Cache API for more explicit caching control.

The session state management built into classic ASP didn’t allow applications to scale beyond a single machine unless you implemented your own proprietary state management mechanism. Although my recommendation for session state remains the same—don’t use it unless you absolutely have to—the mechanism for spanning session state across multiple front-end servers is built into ASP.NET. You can use either a single state server, which stores state for a group of Web servers in its memory, or store state in a common SQL Server back end. Implementing either of these methods requires a simple change in the local Web.Config file. Speaking from my experience with these two mechanisms, I suggest that you store state data in SQL Server to maximize availability and reliability because the out-of-process state server doesn’t offer a significant performance benefit.