Rather than asking a general question about WebForms vs MVC (such as in ASP.NET v/s ASP.NET MVC), I have a specific quesiton.

It appears the main differences between the two approaches are

  1. WebForms is Event Driven and uses pre built components
  2. MVC has a built in layer that WebForms does not: the Model
  3. MVC has the Controllers in a separate folder than the Views while the WebForms Controller is the CodeBehind

One could easily add a folder to a WebForm project called "Model" that stores all the business logic which used in the Code Behind (decoupling the two). The main argument against WebForms is that it's "easy" to write business logic in the CodeBehind. But you could easily add business logic in your MVC controller completely violating the separation of concerns.

Now for the question: Isn't it the case that you could write a WebForms project in such a way that the business logic is separate from the Controller/Code Behind which would have all the benefits of MVC (separation of concerns) while keeping the benefits of WebForms: rich controls, Event driven (if you like events)?

  • If MVC was just a benefit of "separation of concerns" MS could have saved a lot of dev time by just suggesting your approach. Perhaps there's more to it? Control, size of code, performance...
    – JeffO
    Commented Sep 28, 2011 at 13:56
  • 1
    Perhaps there is more. Perhaps not... That is the point of the question. If separation is all then it appears using WebForms with separation is better given the rich controls and event model. After pdr's response maybe a new question would be MVP vs MVC
    – coder
    Commented Sep 28, 2011 at 14:10

2 Answers 2


What you're describing is the MVP pattern. There is a framework called WebFormsMVP specifically designed to facilitate this.

I'm not sure many will agree that it's the best of both worlds, but it is a considerably more testable way to use WebForms than putting all your code in the codebehind class.

However, putting a service layer in between your forms and your data model also achieves this, much more simply.

  • 1
    +1 for MVP pattern. Explain more about the service layer. How would this look, and how would it be better than having each code behind display results from business logic in the Model?
    – coder
    Commented Sep 28, 2011 at 13:47
  • 1
    We found that when we tried to implement MVP, we quickly ended up coupling the View and Presenter together. It was just unavoidable. For a simple service layer, you're just taking all the logic out of the codebehind, passing data from the form into a service method and receiving all the information you need to build the page again. It is not as good as MVP (in that you're not testing that the correct fields are being populated with the data, only that the data is available), but it does come at a much lower cost and that's rarely the code that fails.
    – pdr
    Commented Sep 28, 2011 at 14:07

The biggest difference between MVC and webforms is not separation of concerns, but how it handles state. Webforms tries to model desktop application development by working hard to hide the stateless nature of HTTP and the web. In the process a lot of unnecessary bloat in the form of generated HTML and ViewState gets passed around, making pages slowers and more brittle. Client-side (ie, AJAX-style) development is handicapped as well due to unnecessarily generated HTML elements, and ids generated by WebForm's proprietary naming scheme. MVC removes all this oddness and bloat, embraces the true stateless nature of the web, allows the developer full control over html, and thus inter-operates well with client-side scripts and libraries.


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.