Programmers Stack Exchange is a question and answer site for professional programmers interested in conceptual questions about software development. Join them; it only takes a minute:

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

In my less experienced days I added a lot of business logic in the code behind of my .aspx. Now I'm revisiting it I would like to refactor the mess and get it all sorted out.

How do I go about this? If I am to move my logic, where do I put it? Do I have a seperate class for each page?

share|improve this question

Step 1. Write Unit Test Cases for the business logic. Business rules belong in the model -- mostly -- and you need to rework the model. Some business rules aren't really "business" rules and bleed through into control and sometimes even view. Folks often overstate what's part of the business and what's part of the current business process as performed through the current software.

Step 2. Fix the Model to have the correct business logic. Run the tests. Be sure things really work. You'll often find that you have to rework your model (and sometimes your tests) as you fix this.

Some rules will be in two places: their legacy places and the model. That's okay, temporarily.

Step 3. Start teasing the business logic out of the view/presentation/control layers. This will be hard, and will cause you to rework test cases and model. Rework is good, it's how you learn.

This can get difficult if you've buried a large number of assumptions in the presentation.

share|improve this answer

There are two schools of thought as to the best approach.

  • The most popular is the MVC/MVP approach (Model-View-Controller/Presenter).
  • Equally valid is a more robust model--AKA Domain Driven Development or Naked Objects.

In the first approach, your model takes care of the database interactions, and you organize your logic into the controllers. The most recent variation of MVC web applications provides one Controller class for a set of associated Actions (or pages). Essentially the mapping goes one method per action/page, with a matching view. These web app frameworks (such as ASP.NET MVC) favor convention over configuration and have a decent organization.

In the second approach, all the business logic is coded into the model directly. Business logic and everything. Essentially the more robust model can be reused in both web and desktop environments. It requires a lot more discipline and creative thinking to avoid writing for a target environment.

share|improve this answer

Try adapting your code to a more MVC like architecture, that way your business logic ends up in a separate set of classes (i.e. not the presentation layer).

The controllers is the most complex part of MVC and it's what makes MVC so powerful and flexible.

share|improve this answer

Your experience should help you appreciate the benefits of ASP.NET MVC.

However, if you're most immediately concerned with refactoring your current Web Forms application, you might want to take a look at MVP in ASP.NET Web Forms.

share|improve this answer

There are a couple of books on refactoring C# & by Wrox. They go step by step through the process of code that starts out as you described. Covers OOP enough to get by but isn't intended to be complete on the subject.

share|improve this answer

Your Answer


By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.