Why would you use MVC over Web Forms?

Question

Recently an architect described our company as offering a Rolls-Royce solution (MVC) when all he needed was a Toyota (Web Forms).

I'm curious to find out what you think about web forms vs MVC as an architectural choice.

Answer 1

The Rolls-Royce/Toyota analogy is terribly flawed and misleading. One (ASP.NET MVC) is not simply a fancier or more expensive version of the other (ASP.NET WebForms). They are vastly different approaches to building web applications using ASP.NET.

To me, the biggest architectural difference between MVC and WebForms is how they work with the stateless environment of the web: WebForms works hard to build a set of abstractions that hide the stateless nature of web programming, whereas MVC embraces the stateless environment and works with it.

Each approach has its benefits and detriments, but I really enjoy how building web sites with MVC feels much more natural than WebForms (with its layer upon layer of leaky abstractions).

Answer 2

Old question but it deserves a more detailed answer just in case anybody else out there is still actually having a dilemma over it.

Ultimately, webforms is a thin-client solution by which it's meant that you press a bunch of pretty buttons and the front end (client) stuff is built for you. If you have people who know how to crank it out in webforms and there are absolutely no maintainability/modifiability concerns and the site is completely short term and disposable, there is nothing at all wrong with this approach. It is possible to learn how to do your own stuff but in this case it would require knowing both the web stuff webforms tries to protect .NET app developers from and all the webforms stuff that makes most client-side web devs want to murder the Microsoft engineers responsible.

In the 99.5% of all other use-case scenarios, we've stopped trying to hide the web from app developers because really, if you want to write web apps you're much better off actually learning how the web works. The irony of thick vs thin client solutions is that inevitably the thin-client approach inevitably bloats the crap out of your front end and is anything but performant. More importantly, these solutions have always made things inflexible as all Hell for people who actually know what they're doing and don't want to be constrained by the framework in effect.

There is nothing quite so pointless as taking somebody who knows everything about CSS, JavaScript, HTML, XHR and making them completely useless by roadblocking them every step of the way with a framework that...

• Clears out all 'unneeded' script tags in the head tags to keep you from screwing up on script dependencies. (better to let a 'script manager' handle that for you) Granted, nobody puts 'em up there nowadays if they know what they're doing but that's just messed up.

• Insists you wrap all of the HTML in one ginormous form tag. HTML doesn't allow forms inside forms so you do forms the webforms way or no way at all.

• Creates like an 18-step "life-cycle" for what really should boil down to reacting to UI events by interacting with the browser to send messages to the server and then react when the server responds. Abstracting that process with a big giant pile of garbage never needed to happen (and to be fair, MS isn't the only jackass who's tried to do this).

• Actually does everything it possibly can to get in the way of using non-webforms solutions to problems. Example: When I was a more junior client side dev I spent an entire day finding a way to make a submit button at the top of the page trigger a submit button at the bottom of a page (I assume due to that one-big-giant-form thing). Normally this would take 5 minutes but after quite a few hours reverse engineering the webforms JavaScript responsible, I discovered that they were among other things setting a property I didn't even know about at the time that tells you what the last form element to have focus was so that when a submit button was clicked, only the official Microsoft Submit(tm) button would work in regards to the activation of an official Microsoft Submit(tm) handler.

So no, Rolls-Royce vs Toyota, is completely unreasonable. I would say more, a perfectly reasonable Hyundai that you pay way too much for vs. a Microsoft engineered Pinto with an onboard system that automatically makes sharp 90 degree turns when it discovers you bought gas or oil from somebody other than Microsoft and it's detected a convenient wall to slam into. An ideal car for the suicidally-brand-loyal driver who knows nothing about the web and wants to swear life-long loyalty to Microsoft.

All .NET MVC really is, is simple and reasonable, and it doesn't reinvent its own layer to slap on top of the web. It just works with what's there to help knock out some boilerplate for you. There's better/cheaper/free-er frameworks available but if you've already locked yourself into the .NET thing, you could do much worse.

But seriously, stay the !@#$ away from webforms. It's almost dead now. Let it go. Tell your clients you'll do it for three times the money if they also promise you an exclusive and lucrative by-the-hour support contract for when they actually want to do something new or different or when crap starts breaking because not even MS could be bothered to continue adding to that behemoth of a 10,000 line ajax.js file they pull out of their DLL ass where you can't touch it.

Answer 3

An ASP.NET MVC solution doesn't have to be any more complicated than a WebForms solution. Personally, I find ASP.NET MVC to actually be a lot simpler than WebForms, and it definitely seems to be inherently cleaner.

From my experience, a lot of the MVC frameworks (ASP.NET, Rails, CodeIgniter, etc.) have much of the same core functionality and conventions. WebForms is really the odd duck from a web perspective. My guess is most web programmers would be much faster at picking up ASP.NET MVC than WebForms.

Answer 4

The top reason you would use ASP.NET MVC over ASP.NET WebForms is testability. Sure you can kind of unit test WebForms but this requires mocking frameworks and a lot pain. The second reason is MVC does make it a bit easier to separate concerns. This can provide a great deal of code reuse and make your code loosely coupled. This does not mean it's impossible to do the same in ASP.NET with patterns like MVP.

The downside of MVC is that you lose a lot of the functionality and that has been built into WebForms over the past decade (well almost). MVC has come a long way since its inception to provided similiar features.

As far as performance, does anyone have proof one way or another of which tech is "faster"?

I don't think one is better than the other. I do really like the MVC framework and have used it with great success but I always make sure that I choose the tech that matches the project.