C# ASP.NET Refactoring Codes | How To/ Guidelines

Question

I am facing with a huge task at hand, start re-factoring our biggest asp.net web which created from asp classic, then ported to asp.net VS2003 and then later on ported on asp.net VS2005. Where codes are old school, all business logic & data access are all to be found on the .aspx.cs files. The good thing is, it is working A-Ok.

Now my question is, is there any guidelines on how to refactor asp.net code behind? Such as: - do I need to create a separate class for the refactor codes or should I use the app_code for the new files for the refactor codes? - refactor code structure.. etc.

Answer 1

Well you obviously want to create some sort of Data Access Layer, which you can build as a separate project.

So get all your data access [ADO] code out of the code behind files, and reference the data access layer.

Feel free to use App_Code, but don't over do it. Putting too many classes in App_Code can slow down your build times.

Any General/Utility classes, feel free to put into their own class library project as well.

That should get you started.

Answer 2

I recommend you first extract the business logic into separate classes - don't worry about how they classes are named, or whether another structure might not be better. Just get it done, testing frequently to make sure you haven't broken anything. Later you can decide what classes the logic should really have been in, and can refactor it to put it there.

One of my main reasons for suggesting that is that once the business logic is separated, you can more easily create a comprehensive set of unit tests against that logic. You want to have unit tests in place before you start refactoring to clean up the structure. As long as the unit tests succeed, you'll be certain that your refactoring hasn't broken anything.

That will give you the confidence needed by you (and your Management) to do things like create a separate data access layer.

Answer 3

I'll suggest that as a first step, you minimize the code in your codebehind files. Those should have the minimal code required to retrieve user input, validate, interact with other classes, and provide an output. All the real work should be done elsewhere.

You can create a Business layer (a separate class library) to contain all the real code, which your front end will interact with and delegate to. At this point, you can try adding some integration tests to ensure the components in the business layer work as expected.

With integration tests in place, do some refactoring to ensure separation of concerns, and follow the single responsibility principle. At which point adding unit tests should not be difficult.

If you have data access code, you definitely want that out of your codebehind. Database handling should be done in your Business layer at the least, or better yet database-specific code should be in a separate layer on its own, and used via the Business layer.