Remake old web forms application in asp.net mvc

Question

I've inherited the code maintenance of a complex web site for a customer that continuously requests enhancements for it. This application took years to develop and I'm facing increased difficulties to enhance it. It's organized but at the same time the .net code is mixed with ajax, javascripts and old school html that it takes me days to figure out how some pages work.

First off, I not new to asp.net but I'm not familiar with the new MVC stuff but from what I've read it seems to be a step in a better direction.

The current code is all in one big dll. The application code is divided into multiple folders representing the different departments and each department has it's own pages for handling general stuff like employee management, reports, budget and also their own information.

For example, even though each department uses a different webpage for employee information handling, they want different fields and so it was simpler to create different pages than to use a single page that adapts to each department.

But it is really a nightmare to maintain right now and I would like to create a parallel project where I could start a fresh project, create a better structure and from there start migrating the old code to this new environment and refactor it as I go.

The idea is to migrate the old application to a new web site that has a similar look while maintaining both operating until everything is running in the new site.

It may sound insane but it really is used extensively for hundreds of people everyday and it bugs me that I have to modify crappy code to make it work.

How would you go about this issue?

[edit] If found this link Things You Should Never Do on another post, very much to the point of my question.

Answer 1

Don't be so hasty

I know dealing with other people's code really sucks, but you have to take into consideration that 1- you don't know the new MVC platform, and 2- down the road you will be wanting to remake it again. Consider that rebuilding the project also takes time away that you could use upgrading it.

No Surprises

People don't like surprises in the software realm. I can tell you plenty of horror stories of software that was remade without the client's knowing and upon the surprise revealing, an instant, terrible rejection.

The best solution is to talk to your boss and discuss options. They may even want to integrate more features or go in a different direction. After all, your time is their money.

One More Option

It might be better to spend more time learning it and to slowly build up components that are causing trouble. I sense that you are having some trouble understanding all of the software's functions and going into a remake with those same confusions will only drag those misunderstandings into the new project.

Related SO Questions

• Refactor or Rewrite?
• Refactor/rewrite code or continue?

Answer 2

In my opinion, converting an application that took years to develop to MVC is probably not realistic. It would probably take you just as long to convert it to MVC, becasue the implementation would be totally different, and you would have to find other ways to implement the existing features. I doubt that this client who regularly asks for enhancements would be willing to wait for a couple of years while you're trying to convert it to MVC. From a business perspective, that's just not practical. You would be changing it for you, so it's easier for you to work with, which is not a business incentive for them.

If there is a particular aspect of the system that makes it difficult for you to build enhancements, focus on improving that aspect of the system. Resign yourself to the fact that it's a web forms application, and find ways to make it easier for you to work with. Developers tend to think about what they would like, and how they like to work, but you have to think about the client and how your preferences will impact their business and their bottom line.

My advice is to work within the current design to make certain parts of it easier to work with.

Answer 3

I agree with everything @rlb.usa says. Another risk you have is that you'll never finish migrating the code if you take it one step at a time based on enhancement/change requests.

That may leave you with a bigger maintenance headache than you have now as there will be even less consistency in the architecture. And, it will surely create more confusion for the next developer that comes along.

Answer 4

Unless you have the time and resources to dedicate to rewriting the application ASP.NET MVC and rewriting it properly, don't do it. You'll be in for a world of hurt. I know from experience how terrible poorly-written WebForms apps can be, but it's a Herculean effort to rewrite it to MVC even with the benefits you'd gain.

Would you be better off doing heavy refactoring/rewriting of specific components to make them more abstract and modular, and using MVP or similar pattern to get some of the benefits of MVC without a wholesale move to that platform? That could be a better option. Obviously for any new development that just has to interact with, not be part of, the legacy app should be written in MVC, but heavy refactoring, introducing MVP and proper SoC principles, and slowly rewriting the messiest parts of the code to be written correct will go a lot longer than just scrapping the WebForms behemoth.

Answer 5

There's next to no point in rewriting from webforms to mvc. Almost no code will survive the transition, and as you don't know MVC, the outcome won't be great.

The application code is divided into multiple folders representing the different departments and each department has it's own pages for handling general stuff like employee management, reports, budget and also their own information. For example, even though each department uses a different webpage for employee information handling, they want different fields and so it was simpler to create different pages than to use a single page that adapts to each department.

This will be your saving grace -- I've seen this kind of application. Since each piece of the application is basically separate, you have an option to do piecemeal migration to a more sensible system.

Carve out a location in the URL space of the server where this runs that you can place new code. Rewrite screens one at a time, and test the new code to make sure that it works the way you want. Then change the links and redirects in the old application to point to the new screens, and have navigation in the new screens that link back to still active screens in the old application. Basically, you will have two applications sharing a UI. then chip away at the old application screen by screen as you can and write new code in the new application.

You may have to come up with some way to transfer information between the two applications. You can set the application key in your web.config to the same value to allow single sign-on between the two sides. Try to avoid sharing session state if at all possible (you just get a mess if you do.) Delete old screens as they become obsolete. If there are sensible business layer classes or DAL classes, pull them out into a shared library; otherwise, don't bother.

Answer 6

I answered a similar question (which I don't think is a duplicate). My answer has some good, practical tips on taming a WebForms application.

For you, I would recommend creating a Test project in Visual Studio. Utilize SpecFlow and Coded UI Tests, Selenium or Watin, then test the crap out of the site. Once you've got the site pretty well covered with tests, start refactoring code, one User Control at a time. Follow best practices. The ones below I've used with success in this situation:

• Organize your database access code using the Repository Pattern
• Don't use DataSets in your User Controls. Use Domain Models instead.
• Move all business logic into the domain models. Watch Crafting Wicked Domain Models for some good tips.
• Create helper classes that initialize common controls, such as drop down lists

This is a marathon, not a sprint.