I have written an ASP.NET WebForms portal for a client. The project has kind of evolved rather than being properly planned and structured from the beginning. Consequently, all the code is mashed together within the same project and without any layers. The client is now happy with the functionality, so I would like to refactor the code such that I will be confident about releasing the project. As there seems to be many differing ways to design the architecture, I would like some opinions about the best approach to take.


The portal allows administrators to configure HTML templates. Other associated "partners" will be able to display these templates by adding IFrame code to their site. Within these templates, customers can register and purchase products. An API has been implemented using WCF allowing external companies to interface with the system also. An Admin section allows Administrators to configure various functionality and view reports for each partner. The system sends out invoices and email notifications to customers.


It is currently using EF4 to read/write to the database. The EF objects are used directly within the aspx files. This has facilitated rapid development while I have been writing the site but it is probably unacceptable to keep it like that as it is tightly coupling the db with the UI. Specific business logic has been added to partial classes of the EF objects.


The goal of refactoring will be to make the site scalable, easily maintainable and secure.

  1. What kind of architecture would be best for this? Please describe what should be in each layer, whether I should use DTO's / POCO / Active Record pattern etc.

  2. Is there a robust way to auto-generate DTO's / BOs so that any future enhancements will be simple to implement despite the extra layers?

  3. Would it be beneficial to convert the project from WebForms to MVC?

  • 1
    Release early, release often. I suggest that your client might not care so much if you don't have tangible business issues to present (eg, it's insecure). Perhaps you should clean up a little (make sure it's portable), and release, then take this on as a long term initiative - to morph into MVC or similar.
    – gahooa
    Jul 3, 2012 at 18:03
  • 2
    Don't change your working project technology to new xyz technology just because it is there, specially if your project is working fine as is. If it is working don't break it. Business does not care about the code. Functionality is all what matters at the end of the day.
    – NoChance
    Jul 7, 2012 at 1:55
  • ok that's true, however my concern is, once it is released it will be harder to refactor because of the risk of breaking it when the stakes are much higher. So we would be stuck with code that is not as maintainable and harder to debug etc. I was tempted to learn / convert to MVP but that looked like too much work. So far I have just converted it to DAL, Domain, UI layers which feels more organised yet still allows the inevitable RAD that will be needed while the project is young. One day if necessary I can expand to MVP or MVC I suppose - after I have enough time to learn how it all works.
    – stack man
    Jul 7, 2012 at 3:31
  • What feels messy still is: 1) EF Objects in the UI (code behind files in the UI layer)
    – stack man
    Jul 7, 2012 at 3:31
  • (2) Business logic in extended EF objects which had to go in the DAL layer (didn't realise partial classes had to be in the same assembly) (3) Business logic within aspx.cs files in the UI layer. However, it seems that there are often compromises when it comes to architecture but this is certainly a step forward. I feel that this is acceptable for the 1st release and as time goes on we can reassess our approach. Thank you for your help everybody. It is good to get a bit of direction as this area is so subjective.
    – stack man
    Jul 7, 2012 at 3:43

3 Answers 3


ASP.NET MVP pattern is the best architecture for a long term ASP.NET webforms application. It is coming into play with "separation of concerns" concept, which is de-facto a trend behind the MV* patterns.

The question on Why to use it? - addressed in details in this post - ASP.NET MVP

  • The problem is, it would require a lot of work to refactor the project to MVC...if I keep it as a WebForms app with Domain Layer (code first, POCO), Data Access Layer (db context only) and UI, would you consider this an acceptable design for production? At a later date we could consider converting it to MVC I suppose.
    – stack man
    Jul 3, 2012 at 2:30
  • Well, it is a MVP (model-view-presenter) pattern and NOT a MVC (model-view-controller).
    – Yusubov
    Jul 3, 2012 at 2:33
  • 1
    oh sorry - I misread. Thank you - I will read about the MVP design.
    – stack man
    Jul 3, 2012 at 2:37
  • no problem, i hope you will find what you look for :)
    – Yusubov
    Jul 3, 2012 at 2:38
  • It seems that converting to MVP would also be a major change. The client wants to release very soon, so do you think the above mentioned architecture DAL / DA / UI (although not as ideal as MVP) would be acceptable for this type of application? Then after release we could look at moving to MVP in v2.
    – stack man
    Jul 3, 2012 at 2:45
  1. Use MVP pattern for separate and logic and UI , so in the future you can move to a different UI technology re-using existing logic
  2. Use the repository pattern between BL and DAL so that you can change to any RDBS reusing the business logic
  3. bring separate layers (Dlls) for BO and DAL which is minimizing maintenance.
  • Not sure why anyone down voted this question. To be honest, this is the most concise answer. +1 Mar 28, 2016 at 12:22

As ElYusubov mentioned, the MVP pattern can be great.

The key concept is stripping out most or all of your logic from the code-behind. Logic should not be bound to a page. What if you need to re-use the logic from one page in another? You will be tempted to copy-and-paste. If you're doing this then your project will become maintainable.

So, for starters begin refactoring your logic out of the code-behind and put it in a business layer. If you managed to get all the logic out of the code-behind then you could implement the necessary interfaces to be a true MVP.

Also make sure your data access is separate from your business logic. Create a data layer and begin refactoring on that end as well. Since you're using EF4 this is less of a problem as EF should already have this end separate. You should be able to easily move all your EF files to another project and simply add a reference to the projects that need it. The added benefit being, you may need to reference your data model in other projects.

To avoid being overwhelmed, refactor a little at a time. Whenever you touch a piece of code consider refactoring the code around it. If you do this, over time your project can become more maintainable.


You asked about having the code behind inherit a business logic class. This can't be done because the code behind "is-a" page. C# does not allow multiple inheritance, so the code-behind class cannot be both a page and a custom object. You need to conceptually separate out the logic. Its probably the case that the code in your code-behind is doing many different things. A class should do one thing and one thing only. Try and think about how you may conceptually pull out existing functionality. For example, lets say you have a registration page and you're collecting user information. You probably have a button called register and a click event associated with that button. In that event you are saving user information and doing whatever processing you need. You could create a Registration object to handle all that logic. In the code-behind instead of doing the logic yourself you can pass the information to the Registration object.

This not only a cleaner separation but it can also be a way to self document your code. When someone reads your code they see you calling a Registration object so you know exactly what's going on.

If you wanted to strictly follow the MVP pattern, instead of passing the parameters to the Registration object the code-behind would implement an interface. The implementation of the interface would essentially map all the view objects (text field etc) to the interface. e.g. public string FirstName { get{ return txtFirstName.Text; }}

Once that is done you could pass the page to the Regisration object


And this RegisterUser method would take the interface as a parameter

public bool RegisterUser(IUser user){ user.FirstName ...}

public interface IUser { public string FirstName; }

If this MVP sounds confusing, just focus on refactoring and know the point of all this is to maximize code-reuse. There's no since in repeating yourself. That's the DRY principal.

  • Thanks for your helpful tips. Yes, I have certainly been a bit overwhelmed with this. It seems to me that MVC would be the best pattern to use but MVP would be easier to achieve and would be the next best pattern. I have always used code behind files so always scratched my head about how business logic can be separated from presentation...so I should be able to essentially move my .aspx.cs files to the domain layer and have an inherits statement in the aspx? Certainly ending up with 3 layers would make me feel comfortable with releasing the 1st version - then I can improve it from there.
    – stack man
    Jul 3, 2012 at 18:14
  • I'll respond to your comment in my answer. Feel free to upvote my answer if you found it useful
    – coder
    Jul 6, 2012 at 23:49

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

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