Porting Versus Rewriting

Before converting an ASP application to ASP.NET, you must decide whether you are porting the application or rewriting it. Porting the application involves making only the necessary changes to get it to run under ASP.NET. This is the quickest way to move the current ASP application to ASP.NET, but the time and cost saved now might be spent later as you end up rewriting the application anyway to fully take advantage of the .NET architecture. Rewriting the application enables you to get the most out of ASP.NET, but at the expense of having to throw out much of the work previously done for the ASP application.

Advantages of porting include speed of conversion, the opportunity to learn how .NET works before designing an application for it, and the ability to get the most out of your previous development investment.

Disadvantages of porting include less than optimal performance, higher ongoing maintenance costs, and tying at least portions of your application to legacy code.

Advantages of rewriting include optimal performance, objectization of both user interface and back-end code (which will make it reusable in the future), and lower ongoing maintenance costs.

The only real disadvantage of rewriting is that it requires you to throw away the time and costs involved with implementing the current system, even though these will, to some extent, be recovered through lower maintenance costs in the future.

In addition, applications may be partially rewritten if you want to reach a compromise between a minimal port and a complete rewrite. The better the job that was done to separate the code from the user interface in the ASP application, the easier it will be to convert it to an ASP.NET application that best takes advantage of the features of the .NET architecture. Also remember that it is not necessary to port the entire application to ASP.NET to take advantage of the capability to rewrite portions of it in ASP.NET or add new features using ASP.NET.

Let's look at some sample situations to show how the choice between porting and rewriting will be different for every site. We will look at the following scenarios:

• Small, low-traffic Web site

• Large company intranet

• High-traffic e-commerce site

Each example will have different optimal choices for rewriting and porting. Time and monetary constraints, along with how well a site is designed and implemented, will lead to different choices for real-world sites.

Small Site

In our first example, we have a small, low-traffic Web site. Different people have maintained this site at different times. New features have been added without thought to trying to reuse code or to centralize error handling. Occasionally, the site users will get errors, but because these errors are inconsistent and reloading the page will often result in the correct output, they are seldom tracked down and fixed.

Because in this example the site is poorly coded and error prone, it should be easy to decide that a move to ASP.NET requires a complete rewrite of the site. If a site is too poorly coded, it might even take less time to rewrite all the code than to try to port the current code. Once the site is rewritten, it should be less error prone and require less maintenance provided that the rewrite was well designed. Rewriting the code of the site does not mean that the site needs to be totally redesigned, because it is the code that needs to be rewritten. The visual aspects of the site do not need to be changed, though this can be an opportunity to do a total redesign or to add new features if you thought the site needed an update. Following is a list of things to consider when rewriting the application:

• Separate the code from the user interface ” Separating the code from the user interface enables you to get the most out of your code, and makes it easier to change the user interface when necessary. Use code-behind files whenever possible to make the distinction clear between code used to produce the output and other code.

• Write for reusability ” Writing for reusability means to objectize the code as much as possible. Standalone functions should be grouped into classes that can be used anywhere . Inheritance should be used to maximize code reuse. A good rule of thumb for inheritance is as follows : If you are adding the same basic functions to multiple classes, you should write an inheritable class that contains those functions.

• Centralize error handling ” One reason programmers often give for not handling every possible error is the amount of time that it takes to do so. This is why it is important to develop a standard way of handling errors and centralize this process as much as possible. Using a combination of structured error handling, a class to call for each error, ASP.NET's built-in features for handling unhandled errors, and a centralized error reporting page, the error-handling process can be made as simple as possible. When this type of process is used, errors can be automatically logged so that the site manager can be aware of errors, even without getting a complaint from the end user.

Large Company Intranet

For our second example, we have a large company intranet. In this case, the site was well designed using COM objects to encapsulate all the business logic. Because a lot of money was spent developing the site and the COM objects, saving as much of this investment as possible is important.

This example is a good argument for porting. A total rewrite would cause you to lose a large portion of the time spent doing a good job on the current implementation while providing minimal gain. The ASP code can be ported, and the COM objects can continue to be used. The COM objects can be rewritten to .NET classes at a later date if significant changes to the business logic are required or if it is determined that any performance gain is significant enough to make it worthwhile. Following is a list of considerations when porting an ASP application:

• Use Web Controls ” Using Web Controls will involve rewriting portions of your code, but it will make it easier to change your application later using Visual Studio .NET. If you have common groupings of controls, you might want to take the time to write a custom control.

• Switch to structured exception handling ” Structured exception handling is more robust then Visual Basic's On Error Resume Next type error handling and allows you to more easily handle all errors. Changing your error handling now will also allow you to use structured exception handling when you implement new features.

High-Traffic E-Commerce Site

For our last example, let's look at a high-traffic e-commerce site. This site has been reasonably maintained and documented. It uses COM objects for the business logic, much like the previous example. The main difference from the large company intranet is that this site can't be down for even a minute because the company depends on the revenue generated by this site. Also, the site is constantly being updated with new features to differentiate it from other e-commerce sites, and this continual addition of new features can't be stopped for the length of time necessary to do a complete port of the application.

In this situation, the best answer would be to continue running the current application under ASP while adding new features with ASP.NET. As time allows, different segments of the application can be ported or rewritten one at a time. This method enables you to get started using ASP.NET and take advantage of its new features as soon as possible without taking the time to convert your current application. The main thing to be careful of is that Session and Application data is not shared between ASP and ASP.NET. If you are storing data in the Session or Application variables , you might need to develop a custom solution to share this data between ASP and ASP.NET.