Classic ASP to ASP.net or ASP.net MVC

Question

We have a web application which is developed in classic ASP and it evolved over 5 years to its current form which has 100's of pages, huge database and more than 10000 active users going through at least more than 10 pages daily.

Now, we wanted to upgrade it to latest version of .net. Initially we thought rewriting the entire app, but after analyzing the scenario we found that is not a viable option also not suggested by many experts. We have not yet decided on how to do it in otherway, but got some thoughts on how to achieve the rewriting in faces.

Option 1: We thought of identifying the main modules in this application and rewriting them one by one by separating the application into different layers such as database (existing), then business logic and the view. This way newly developed modules will be added to existing system and new pages will replace old pages in that particular module. At the same time we can test the new layers alongside old system and release them once we feel confident. We also thought of developing API kind of structure for business logic and this will be accessed by view as an external application.

Option 2: At the moment we have done a simple module and used it in classic ASP page through an IFrame, though it was quite troublesome sending data between classic ASP and new page in the IFrame.

This is just in planning stage on how we should achieve the rewriting of the entire application without disturbing the user base.

I want to get other programmers views, opinions and suggestions on should we approach in such scenario? if anybody has faced this kind of scenario please share your opinion too.

Also would like to know using of ASP.net MVC is going to help me in this?

UPDATE: Thanks for both the answers for putting up your views. Would like to get more inputs on both the options I specified above in migrating the application from classic asp to asp.net or asp.net mvc. It would be great help for me, if you all can through your views, points and thoughts on migration part rather than the point of choosing asp.net or asp.net mvc.

Answer 1

Let me start off by saying, "I feel your pain, brutha." I went through this 3 years ago, and I wish MVC had matured at that point because the WebForms solution I designed fairly well resembles the MVC model without actually having the Microsoft libraries built for me (of course, there were several glaring "Why the hell did I do that" differences).

I also ended up using iFrames to manage the content differences using .Net as the parent application and classic asp as the slave. I developed the framework architecture in .Net and implemented that. The classic asp pages were then "culled" of unnecessary presentation pieces (includes and whatnot) and loaded into iFrames. Data was then passed in through the url using a custom encryption. To make sure that the authentication could not be spoofed easily and the page accessed by cracking the query string we also employed Wildcard handlers in IIS that forced .Net to authenticate before parsing classic asp pages.

Given that, my recommendation would be to head to MVC straight away.

1. MVC will give you access to routing at the global.asax level. With clever manipulation of a controller, you could develop your models in a proper fashion and have a common controller that handles all classic asp requests as necessary.
2. MVC will make it very simple to add a test project and allow you to refactor individual application pieces based on the new model structure while providing adequate test coverage to make sure you're getting it all right. The value of this is absolutely incalculable because in any refactor code coverage is a huge concern.
3. MVC follows a more scripted approach to presentation than WebForms does. WebForms tries to mix it all up like it's some kind of stateful application (which it isn't), and that can be quite a culture shock for people accustomed to classic asp. Don't get me wrong, your developers are going to have culture shock no matter which way you go, but if you can take some of that shock out of the presentation layer you might find greater success.

I like both WebForms and MVC (though I'll admit with the introduction of Razor I'm becoming a little biased towards MVC). They both have their places, and I think an application such as the one you describe may be ideally suited for an MVC implementation particularly given the "staggered" nature you'll need to adopt in rolling out refactored application pieces.

Whichever way you go, I think you need to make sure that the .Net application is always the parent application when it comes to authentication/authorization/routing/etc. A colleague of mine implemented his migration on a similar application with classic asp as the parent, and he had a large number of problems when it came finally to integrating everything back together.

Answer 2

Going for ASP.NET MVC isn't going to make the transition any easier necessarily, and it may in fact may make it more difficult. However, when you've already elected to go through this grand undertaking, why not take the time to go ahead and move to the platform that fits your plans the best?

Migrating to ASP.NET (sans MVC) will be "easier" in the sense that you can generally do straight ports of your existing logic without having to do a lot of grand refactoring, provided you aren't doing a lot of exotic things with classic ASP. The results will be satisfactory and relatively familiar to the folks who are already familiar with the application. You'll achieve benefits in the sense that every application ported from classic ASP to ASP.NET receives benefits.

Migrating to ASP.NET MVC is going to be more work. It will likely require rearchitecting your application model to fit within the MVC pattern. This is generally a Good Thing(tm) because it encourages good behaviors like separation of concerns. The resulting application will not likely closely resemble anything you have existing except for the core logic pieces. You'll get other advantages as well. It will be a large culture shift and it will take some (re)education of the development team to understand "how to write MVC" properly.

Of note, Microsoft is not abandoning WebForms according to ScottGu (as of a year ago), but I don't think it's difficult to make the call that if/when they do decide to phase one of these two technologies out, it will be WebForms.

Answer 3

I totally agree that ASP.NET MVC is the way to go. It won't be easy, it won't be easier, but it's certainly a lot more future proof than WebForms. While WebForms certainly hasn't been abandoned, applications using them get increasingly cumbersome to mantain as the applications grow larger and larger.

I strongly discourage the use of WebForms on "big" applications.

Answer 4

I like Option 1) (with MVC) much better than Option 2) as it allows you to evolve the application incrementally, while not having to couple the two apps too much as you would with the iFrames approach.

I've had some experience with migrating an old app to ASP.Net and one of the challenges was sharing some of the resources such as session state between the two apps. That can be solved by having one app call the other on the server side via the cookie information from the user's browser. Other sharing of information between apps can also of course be done via URL routing and query strings which is a natural approach with MVC.

Also, identifying appropriate modules to migrate first can be a challenge, but you could start with all new functionality being developed on MVC to prevent more things ending up in the garage to be migrated. Then perhaps pick sections that have a significant backlog of rework or bug fixes to be done next as the MVC app would then become a form of refactoring, using your old system to establish the expected results as you suggest. Don't forget to also take advantage of MVC's testability by adding unit tests and automatic acceptance tests (e.g. SpecFlow/Watin) during this refactoring. One advantage of the latter type of tests is that you could verify that they pass on the old system and then apply the same tests to your new code for this and future refactorings.