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

WebForms is Event Driven and uses pre built components

MVC has a built in layer that WebForms does not: the Model

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...
–
JeffOSep 28 '11 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
–
coderSep 28 '11 at 14:10

+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?
–
coderSep 28 '11 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.
–
pdrSep 28 '11 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.