Cleaning up a complex WebForms project

Question

I'm currently working on a high-traffic online search site.

They have various changes they want to implement over time, and they've indicated that ultimately they want the site re-done in ASP.NET MVC.

Currently the site is an ASP.NET WebForms project; however true ASP.NET controls are rarely used. Instead there are lots of server-side tags - i.e. <% ... %>. The code in these tags will usually be a call to a static method in a static class or a fragment of C# code that generates HTML.

Many of the static methods generate HTML by appending text to a string-builder and returning it as a string.

I understand the concept of a 'Helper' method, but I don't like the idea of the HTML being rendered by concatenating it to a string variable. I think they'd be better off using 'Partials'.

The thing that concerns me is that it's a pretty complex site, and I'm not sure if a complete rebuild of the site in ASP.NET MVC is a good idea.

In spite of the bad structure, it's not really that hard to add the new features that are being requested. (Perhaps because I've had past experience working with difficult code).

However I think there's a risk that at some time in the future, a requirement will come along that will be very difficult to implement unless we do a complete clean-up of the code-base.

I want to put this question out there and see if anyone's faced a similar issue, and how you dealt with it.

Also what are your thoughts on doing the re-build as a 20%-time side-project? Are there any downsides to doing it this way?

Answer 1

Wow, this is some project.

Personally I think any site written in ASP.Net will need to be totally re-done as far as the UI is concerned. MVC does it a whole lot differently.

Your business logic on the other hand should be ok though me thinks so long as you have seperation of concerns and it's not bound to the UI.

Data access should be ok and probably needs minimal touching. But that again depends on how tightly bound your web site is.

I think the best approach is to spend some time looking at how MVC does business and do a critical analysis of what it would take to convert and then begin converting all the layers above the UI in preperation.

Get your foundation in place and maybe even, if possible, use the MVC framework already. Again, only if you can and only if viable.

Doing this as a side project would work I think because you can take some of your libraries and begin converting them in preperation for the mvc conversion.

But be mindful that once you have converted a project/layer that you (do) implement it else it runs the risk of being forgotten or changes get made to the other layer that then need to be coded into the new etc. You know the traps.

As for the UI, that's going to be the big one especially if you use a lot of asp controls. You maight want to spend a lot of time evaluating the UI and come up with a list of controls that you either need to replace or write. Then you can begin to see a pattern and get some consistency going.

If you have a lot of code in your code behind, you may want to begin moving this to another layer as this will help later on when you create controllers etc. They can then instantiate your new layer and all should be good.

That's all I can think of from the top of my head. I'll edit or comment as I think of things.

Hope this helps.