Refactoring an ASP.NET 2.0 app to be more "modern"

Question

This is a hypothetical scenario. Let's say you've just been hired at a company with a small development team. The company uses an internal CRM/ERP type system written in .NET 2.0 to manage all of it's day to day things (let's simplify and say customer accounts and records). The app was written a couple of years ago when .NET 2.0 was just out and uses the following architectural designs:

• Webforms
• Data layer is a thin wrapper around SqlCommand that calls stored procedures
• Rudimentary DTO-style business objects that are populated via the sprocs
• A "business logic" layer that acts as a gateway between the webform and database (i.e. code behind calls that layer)

Let's say that as there are more changes and requirements added to the application, you start to feel that the old architecture is showing its age, and changes are increasingly more difficult to make. How would you go about introducing refactoring steps to A) Modernize the app (i.e. proper separation of concerns) and B) Make sure that the app can readily adapt to change in the organization?

IMO the changes would involve:

• Introduce an ORM like Linq to Sql and get rid of the sprocs for CRUD
• Assuming that you can't just throw out Webforms, introduce the M-V-P pattern to the forms
• Make sure the gateway classes conform to SRP and the other SOLID principles.
• Change the logic that is re-used to be web service methods instead of having to reuse code

What are your thoughts? Again this is a totally hypothetical scenario that many of us have faced in the past, or may end up facing.

Answer 1

You missed the first step that I would go through:

Cost-Benefit Analysis

Refactoring an app because you think it feels old is not a good reason. It's still running (I'm guessing fairly relaibly by this point) and your company already has a lot of time and money invested in the code.

You probably also have a team of developers that are familiar with .NET 2.0 and WebForms whereas many may not understand the concepts/code you're trying to introduce.

Before changing anything, figure out how much money is invested, how much money you're going to spend on your changes, and how much money it'll save in the future...

If the numbers don't add up, no business is going to let you proceed.

Answer 2

1. Make sure you have a complete suite of tests to cover the existing code before you go tearing it up.
2. Write new features using your new techniques.
3. Update old code to the new techniques if it needs modification because of a feature request.
4. Refactor old code that doesn't need changes only if you are bored and have no new features to write.

Answer 3

While it can be tempting, I personally would not make these major changes to the architecture of the application unless they are satisfying specific user requirements. Simply implementing these to make the application better in terms of maintainability sounds like a big risk. You may get 60% of the way through and find major challenges with getting one of these changes to integrate with the rest of the legacy application. It sounds like you'd almost be facing a complete rewrite of the application to ensure everything is consistent with the new architecture. You may invest a lot of time into the rewrite, and find that the maintainability has only improved a little such that recapturing the time invested in the rewrite will take a long time.

If it were really poorly written or in a legacy language like VB6, I would personally say it would be a candidate for a major rewrite. However, .NET 2.0 is a very capable language and for alot of applications is not crippled. From your description it sounds like the application is pretty well designed as is. It actually has a data access layer, business objects, and is layered in some way. This sounds like a pretty good application considering you can identify these attributes. Consider yourself luck that this isn't some app where it's such a mess you can't pick out anything that resembles a particular design pattern.

Maybe there are places where the things are a little nasty, but sometimes it's not pretty where the rubber meets the road and things get wired together.

Answer 4

I agree with other posters, dont rewrite unless you can demonstrate the cost saving benefits.

What you could do is write new areas of the system using eg entity framework, MVC and jQuery because the difference will be transparent to browser users. In time you can move the legacy code over bit by bit as you make upgrades/enhancements.

Its also always easier to implement new technologies on new system code, rather than porting existing code.