On the surface, I suppose this is YAMVCVWFC (Yet Another MVC vs. WebForms Comparison). If this topic doesn’t appeal to you, or you’re sick and tired of this discussion then I encourage you to move on. I won’t be offended, promise. This post is here to serve as my living, breathing arguments for fighting for MVC and it will serve to highlight my major gripes with Web Forms.
The motivation for this post came from an all-too-familiar IRC chat in #asp.net – for those of you unfamiliar with IRC, it’s a lot like the Twitter of the 90s.
(01:29p) <webformsdev> 99.9999999999% of client requests, project requirements, etc etc, can easily and equally be done using webforms or mvc (01:30p) <webformsdev> webforms + jquery = does everything I need (01:30p) <@mattman> getting something done, and getting something done in a testable, maintainable, long-term way, are entirely different
(01:33p) <webformsdev> how is <%HtmlHelper%> innovative (01:34p) <@mattman> HtmlHelpers are 4% of the ASP.NET MVC platform. That’s like saying <asp:Textbox> is all of asp.net webforms (01:35p) <@mattman> http://www.codethinked.com/post/2010/01/22/Controls-Do-Not-Make-You-More-Productive.aspx
(01:41p) <webformsdev> but i believe if you know how to use webforms, properly, you don’t encounter that bullshit (01:41p) <@mattman> no one knows how to use webforms properly (01:42p) <@mattman> developers every day struggle with dynamic controls and databinding in even slightly-complex real-world scenarios. Mindlessly tweaking code and refreshing the page to see what ASP.NET will render. (01:42p) <@mattman> Commenting and uncommenting out blocks of if(!Page.IsPostBack) logic, moving chunks of manipulation code from PreInit, to Init, to Load, to PreRender. All Trial and error, ad infinitum. (01:42p) <@mattman> I’ve personally wasted more time on that than I ever care to admit
(01:43p) <@mattman> Here’s the thing, I hate black magic, I hate not knowing what’s going on in my framework, especially when you get UpdatePanels involved, etc. Its an abstraction I just don’t need. It doesn’t make me faster, more productive, help other developers understand or maintain my code later, or help me understand how things are really working in case I need to dive in and debug. You just tweak it ‘til it works and then go home (01:43p) <@mattman> MVC has none of that. It’s just HTTP, GETs and POSTs, with a pluggable model binding mechanism, pluggable validation, some scaffolding options if you want them, etc.
(01:44p) <webformsdev> mattman, then you must really like PHP too, minus the lack of IDE/framework (01:45p) <@mattman> I have done plenty of PHP work. Which is why I was able to adapt to MVC quicker than most with a WebForms background. 50% of ASP.NET Web Forms developers have no idea what an HTTP POST is. (01:45p) <@mattman> I liked the web side of PHP very much. I liked knowing at a glance WHY something was being rendered a certain way, even if it wasn’t entirely maintainable and a big mix of logic. I liked for loops to build my grids, with condition logic plainly visible to tweak a row based on some “data binding” logic
(01:46p) <@mattman> INSTEAD OF Repeaters with OnItemDataBound and runtime casting an e.Item.DataItem object, getting properties on that object state, and then using e.Item.FindControl to manipulate the data binding template – with EVEN MORE most casting and runtime failures (01:46p) <@mattman> ItemDataBound and the likes are completely counter-intuitive and cause developers to really hunt around looking for rendering logic in the template itself, the code-behind, etc
(01:47p) <@mattman> Web Forms has is so tightly coupled at every layer it makes true separation of concerns almost impossible. The Page is instantiated by the runtime, making ground-up use of an IOC container inflexible, and a burden to say the least. WCSF from P&P helps with this, but having used it on a large project it was not nearly as useful as MVC has been. (01:47p) <@mattman>The MVC designers recognized this and created the ControllerFactory class for us, so using IOC and a container can be seamlessly used from the start of the request pipeline. MVC is entirely extensible and pluggable at every stage.
This wasn’t discussed in the conversation, but I will throw it in. MVC is testable, simple as that. Not many care about testing – in fact far fewer than I wish unfortunately. But it is becoming increasingly important in professional development shops. There have been tons of debates that I wish I had the logs for on this topic, ranging from people swearing that Web Forms is testable if you are careful, etc. But the fact of the matter is, people are not careful. We’ve all seen the reality of modern ASP.NET development, people don’t like to think about where their code goes – just put it in the simplest place that could work (code-behind), load the page, and call it a day. Regression bugs run rampant in many ASP.NET projects because it is so tightly coupled that changing a single user control by removing some if(!Page.IsPostBack) logic causes a huge cascade of failures in pages you never even heard of. MVC intuitively gives the Views so little power that it is actually more of chore to put some untestable logic into this “quick fix” than it is to do it the right way.
I will never forget the look on a friend’s face when I told him that ASP.NET forced developers to use one <form> per page. This friend was a classic ASP developer and has since moved on to other things, but the sheer notion of this limitation literally made his jaw drop. This is such a ridiculous constraint on Page developers that I can recall first moving to ASP.NET from PHP and having such a hard time getting my head around such an outrageous constraint. MVC takes developers back to the way the web was meant to be utilized. This single change offers so many benefits I am disappointed with myself that I left it so far down the list.
That about wraps up the 20-minute conversation. I will probably be amending this post in the future should any new areas for discussion come about. Comments are welcome!