Migrate, Integrate, or Rewrite?


The first question that needs to be asked is, should you migrate at all? Is the effort going to be worth it? No one can deny that ASP.NET is better than ASP in many (if not all) areas for developers. The whole environment promotes cleaner code, better reuse, and faster applications “ many developers would love to work in this better world. However as you move forward with your development, there will be costs involved, and you must weigh up those costs carefully to decide which option you should choose.

For example, ask yourself the following questions:

  • Is the application purely ASP pages.

  • Does it use COM components .

  • Do you have a data tier in MTS or COM+ Services.

  • Which browsers is it targeted at.

  • Does it use client-side script.

  • Do you need to migrate at all.

The answers to these questions will help you decide the action you need to take. Unfortunately, there's no simple answer “ almost every application is unique, and must be considered independently. The one thing that's critical about the process of migration is to set your expectations at the right level. Don't think you can just rename your pages to .aspx and expect miracles to happen.

Migrate

Migration can be described as the movement of all parts of an application to a new environment, with the minimal amount of code change. This is often the goal many people aim for, but it can have hidden costs.

For example, will the new application be easily maintainable ? Will you add code to bring the application into line with ASP.NET, but in doing so leave code that is even more confusing than it was before? The short- term cost of performing the least work might actually turn out to be more expensive, if, further down the line, more work is required. You should analyze the cost of this approach, comparing it to the cost of rewriting, and see which has the greatest long-term benefit.

Integrate

Integration gives you the ability to add new ASP.NET features to existing ASP applications, or perhaps to migrate only selected parts of an application. In many ways this is a good approach, but it also comes with pitfalls, the two most obvious of which are:

  • Built-in session and application state cannot be shared between ASP and ASP.NET applications.

  • Sluggish performance , as crossing the managed/un-managed code boundary incurs a minor performance cost.

Usually you'll find that the latter is acceptable for your particular application “ after all, the application will still work, and the new ASP.NET code will run faster, so the benefit of using new code might equal out any performance drop. Also, when all things are considered, the boundary crossing is light compared to some other actions (such as database access). The first bullet point, though, is a big problem “ you can easily integrate ASP.NET pages into an ASP application, but there's no way of sharing built-in state. So, unless your application uses its own form of session storage (such as a database), or doesn't use the in-built state handling, your options are limited.

Integrating ASP.NET applications with existing COM components only suffers from the minor performance hit of the unmanaged/managed code boundary, unless they use the ASP context. In this case you may need to alter your ASP.NET pages. We'll look at this topic later, when we look at the ObjectContext object in the Intrinsic Objects section.

Rewrite

Rewriting is the option many of you would like. Starting again from scratch is not only a great opportunity to get the best from the new platform, but it's also a chance to cure some of those things about the original application that you never liked . This option will, of course, get the best from .NET, and in the long run may be the cheapest solution. One of the reasons why the ASP.NET team decided to break compatibility with ASP was because you have more Internet time ahead of you than behind you; the future of the Internet is more important that its past. Microsoft wants a platform that will last for a long time. Of course, one of the big problems with the rewrite method isn't with the code itself, it's with education. With a new technology such as .NET, it's often the training and experience that prove too much of a hindrance to this option.

Do Nothing

No matter how much you might want to take one of the preceding methods doing nothing might actually be the best bet for your applications. After all, do you really need to move to .NET? What sort of business case can you put forward to justify it? How much will it cost? Conversion (whatever form it takes) means time (and therefore money) for developers, testers, bug fixing, and so on. The whole development cycle has to be gone through again. Remember the old adage “ "if it ain't broke, don't fix it". It's nice to play with new toys, but sometimes a good old-fashioned wooden train set works fine.




Professional ASP. NET 1.1
Professional ASP.NET MVC 1.0 (Wrox Programmer to Programmer)
ISBN: 0470384611
EAN: 2147483647
Year: 2006
Pages: 243

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net