Refactoring techniques for asp.net webforms application

Question

I'm working on a large application written in asp.net web forms. It was developed under asp.net 1.0, and still uses DataGrid, though portions have been updated.

Most of the code resides in either the codebehind, or in controller classes that can't be instantiated outside of a running IIS. (The controller framework we use provides lifetime management tied to session state.) Data access is through a custom DAL, meaning that most of that code also requires a live database with proper data inside it.

I want to decouple the code from the database and the web server, so that I can run it under a test harness. Are there any good strategies for moving from this sort of code to a more testable structure?

Answer 1

The best way would be to refactor out the code-behind to logical layers (services, DAO/Repository, etc). Look at Model View Presenter for ideas how to abstract away the rest, but realistically an endeavor like this is usually better served by rewriting the thing properly; speaking from experience it's very hard to refactor WebForms when it's done terribly, chances are you will have to redo so much that you're basically rewriting the thing anyways.

Answer 2

The problem is. that with the information you give, the range of possible answers is theoretically infinite.

If I collect the hard facts I get the following picture:

• ASP.NET 1.0 Webform
• DataGrid
• Tight coupling
• Dataaccess via custom DAL

Besides that, you didn't say in which direction your refactoring is heading. Simply »cleaning the mess« is a good starting point, but not enough. And as @Wayne poined out: it would end up effectively in a rewrite.

There are at least 2 possibilities:

1) Making a SPA where you have a smart frontend and do most - or at least a good deal - of logic in the frontend

2) Making a conventional web application with WebAPI. Besides, though I actually have not worked with it, but perhaps it is worth a glimpse: NancyFX

Depending on how big your application / codebase is - and on how hip you want to be, you should think about using microservices

Some easy recommendations are:

• Replacing the Datagrid with a JS-equivalent: datatables.net or jqGrid

Data access is through a custom DAL, meaning that most of that code also requires a live database with proper data inside it.

• This could be mocked or stubbed away

For the rest, it depends:

If the codebase is somehow in shape. Try to guess, what the code does. Write a test. See if your assumption holds. If so, write another test, to veriy another assumption. If the PITA-factor is too high, rewrite the business logic completely. Otherwise repeat and build an iterative refined understanding of the code and evolve a finegrained test suite. Step by step you are knitting a saftey net around the code. If it is tight enough, take the chainsaw and cut the code in handy pieces.

I have to admit, that this is a very general advice, but without further knowledge of your codebase, it is hard to give any concrete advice.