ASP.NET Web Forms versus .NET MVC: Comparing apples with.. really old apples

I'll say it up front, I'm tired of using Web Forms :) I'm a professional web architect (it sounds huge, no it's not. I just do that for a living) and I personally think that it's a counter intuitive framework to deal with. I can't do MVC often since nobody around me is using it (I'm not mad at that fact by the way). But it's a shift I'd like we do, and why we should do it is the main goal of this article.

So walk through the light Homer!

Table of Contents

• Introduction
• .NET Web Forms
  
  • The beginning
  • The Problem
• Smoke and Mirrors
  
  • View State
  • Controls
  • Page Life Cycle
• How Web Forms Swims Against the Wave
  
  • View State
  • Controls
  • Architecture
  • Verdict
• The .NET Model View Controller (MVC)
  
  • Background
  • MVC Versus the View State
  • MVC Versus Controls
  • MVC Versus the Page Life Cycle
  • Last Words on MVC
• Conclusion
• Next Steps
• Related Articles

Introduction

Hi,

From my experience, I've witnessed some changes in web development since year 2K. This article will essentially focus on the history of the Web Forms framework and its key aspects while comparing them with MVC. So instead of promoting MVC, I'll show you why Web Forms is bad for your health. After that, you'll go wherever you want! I will also put some code sometimes to show you the differences between the two but don't expect a feature by feature comparison, there's plenty of web sites on the topic.

Web Forms

The Beginning

Let's talk about the beginning of Web Forms and the .NET era. The ASP.NET Web Forms framework was released in January 2002. I built my first web page 7-8 years before that in notepad. I was also building web sites professionally for 2 years at that time.

To my knowledge, it was the first serious object oriented framework (again, to my knowledge). So it was quite interesting and also a big thing. The community desperately needed a true widespread object-oriented framework. The Microsoft IDE was also great since they had enormous experience in that field (with MS VC++ or VB). It was well received by the developers and well adopted. I was thrilled myself and I used it for 3 or 4 years and I'm still using it today (see introduction).

The Problem

Maybe the problem with Web Forms was actually from the experience the Microsoft Web Forms team had previously with other programming frameworks. I did a Microsoft VC++ certification a while back and this is the thing that got me thinking about the flaws of Web Forms. The certification was about creating Windows desktop applications. It was about creating forms with buttons and putting labels in the form and such, rings a bell?

That's right, all in all, the biggest error Microsoft did was to try to encapsulate web sites programming into desktop applications programming. Again that's my personal point of view but... a colleague of mine told me the exact same thing about Web Forms not too long ago while I was writing this. Funny coincidence! What's even more funny, is that the guy didn't knew until recently how to send a regular mail envelope, with a real stamp! So, huh humm, basically anyone can agree on that point! (I'm messing with you colleague ;))

Smoke and Mirrors

So we've been doing web sites for 9+ years now with something that tries to make it like it's desktop application development. But how they did it? How it works? Let's see some basic Web Forms "features" that makes it possible:

View State

The biggest difference between desktop applications and web applications is the notion of state. In desktop applications the application is in memory on the client's computer. You can set variables and retrieve them at will. You can click a button and everything else on the form stays like it was before because it is in memory. Well, you get the general idea.

In web development, there's practically no state. You navigate to a page, the previous one is gone. This is because the HTTP protocol is all about (almost) anonymous requests and responses. To overcome this problem (reliably tracking a client), servers implement what is generally called a session: a cookie that travels back and forth between the client and the server so that the server can uniquely identify a returning client. The server can then keep some data associated to each of its clients on its side (according to the application's needs and only for a certain amount of time). Well, the View State isn't like that at all. Even if the session could bring state to the table.

So why all the explaining? Sure the session can bring a sense of state between the client and the server. But the View State implemented another mechanism to keep the state between the client and the server. An example of a state-keeping web page would be like: if I click on a button to submit a page, I want the text boxes in that page to retain their values after the click (just like in a Windows application). After all, their values should be gone since it's a brand new request and a brand new response. It would have worked with the session (details skipped) but maybe the things we wanted to keep track in it would be too big. The server would have to store all sorts of data in the session and it would have taken servers down (remember, session is stored on the server). So they said to themselves: "okay we want to mimic a desktop application, we want a notion of state across page submissions. We can't store that state on the server, what can we do?". They decided to move that state on the client (in the resulting web page sent to the client). That's right, all the things the page want to keep track of is sent to the server, then the server sends it back along the response to the client. The View State is born. The View State acts as the "local memory" of the web application (as the local memory in the desktop applications) and is hosted in the web page client side, hidden from the presentation. In other words, the state is implemented as a ping pong game, the ball being the View State.

Normally, with some existing frameworks back in the days you would have to mimic the mechanic yourself according to your needs. It was pretty cool to see it working out of the box at first I have to admin.

Controls

The next thing Microsoft did to, again, makes you believe you're doing desktop application development was to create "server side" controls. Just like in desktop application development, in Web Forms you have labels, text boxes, panels, buttons, etc. They work hand in hand with the View State to initialize and render themselves and such. You place them in in the web page just like controls in a form. In the code behind you can manipulate the behavior, style, content, events, etc... of the controls. This is a two edged swords but I'll talk about it later.

Page Life Cycle

When you say buttons, you say events. In desktop applications you have events: when the forms loads, when a button is clicked, when it is destroyed, etc. The page life cycle takes care of everything regarding events in Web Forms and acts as the same thing in a web application.

So there you have it (basically), the smoke and mirrors of Web Forms. There's plenty of other things in Web Forms that makes it what it is, but I'm focusing on its building blocks here and already it's more than enough to understand how bad it is.

How Web Forms Swims Against the Wave

Well what's bad about trying to make things easier? Making things easy for developers!? Sure it's easy! I can tell you myself it's viable. For simple examples you find on the Internet that's fine! It's stops there. Why? Because having those things around (View State, Controls, Page Life Cycle, etc), it comes at a price. A price I'm not willing to pay and I'm not even talking about performance here but learning curve and productivity. Also because the roots of Web Form are based on complicated things not meant for the problems they are trying to solve. Sure the examples in your books are working perfectly, simply because they're showing you mimics of some desktop applications. Not professional modern web applications. Let's go through the previous list to see how they just don't work in a professional grade web application.

View State

First, the View State can be huge. It is transferred between the client and the server on every form submission (every so-called event) so your application consumes more traffic. It is not compressible by http compression since it is composed of random-like characters. It can become corrupt between the client and the server (Validation of viewstate MAC failed remember?). Since the View State constantly travels between the client and the server it must be secured. We don't want a client nor a man in the middle to forge a View State. So there's more and more considerations and things involved. More and more complexity. You also have to keep that in mind with Web Farms or when you're doing load balancing without affinity: what if a page request is made on a server and its submission lands on another? The submission won't be allowed because the View State security involved between the client and the server wasn't initiated by the second server. Sure it's configurable, but you said it, you have to configure it!

Another thing. To make View State possible, your page must also have one and only one form tag that wraps the whole body of your document. Because any "post-back" (button click, pager click, drop-down changed) can trigger a form post to the server (and the controls can be anywhere in the page and we want to keep the state of each and everyone of them), a form must wrap them all. What if I want to have a separate form? What if I'm doing a mobile version of my web site that doesn't use JavaScript. You're stuck on using Web Forms compatible components and following the mold.

Controls

As I said, there's plenty of controls in Web Forms. The problem is that there's never a 1-to-1 association between a Web Forms control and an HTML element. You understand why: they're meant to be controls for a desktop application. Let's look at an example:

This Web Forms control...

<asp:HyperLink
    ID="HyperLink1"
    runat="Server"
    NavigateUrl="http://www.google.com" CssClass="ridiculous"
    Text="Hello World"/>

Translates to...

<a href="http://www.google.com" class="ridiculous" ID="Ridiculously1_Long1_AlwaysChanging1_AccordingTo1_Context1_HyperLink1">Hello World</a>

There's some confusion here right? Let's take a look also as the asp:Label control. The asp:Label tag will translates into a span HTML element when rendered on the page. But if you set its AssociatedControlId attribute, it becomes a label HTML element!

Now let suppose I'm at the beginning of my career, I've studied hard to do some HTML and CSS, and then I open my first project at my brand new job and I see that. I would probably think that either my course was a complete rip off or, that the industry moves so fast that walking wasn't fast enough to get to the job that morning. Seriously, you immediately ask yourself those questions: How can I put inline styles, how does the server control translates to the client control? What's the CssClass property, aren't we using the class property? Should I put the runat attribute on everything? I'm confused! Well, me too.

In the end, the problem is that they never thought you would have to look at the resulting page source AND they never thought that someone else besides you (a developer) would have to take a look at the HTML source code (.aspx). But guess what, you're not alone to play in this project and your co-workers are certainly not always Web Forms developers (not even .NET developers). Nevertheless, we all have a thing in common: we know HTML.

Architecture

Before we wrap up about Web Forms and start talking about MVC, there's one last thing I want to point out, it's how Web Forms behaves on architecture. A good architect will finds its way in any framework, let me clarify that. But I feel that Web Forms encourages by nature a bad architecture. I think that it starts with the user controls: You can manipulate them client-side AND server side. It creates an open bridge between 2 of the 3-tiers of your application (presentation and business). You can change the CSS of a control from within the code behind. You can register a script from the code behind. When you do that kind of stuff it's like taking a sheet of paper and folding the first tier onto the second. If by any chance the 3rd tier is tightly coupled with the 2nd, everything folds into a big paper ball ready for the trash can... I meant the recycle bin of course (yeah I'm green).

Verdict

Web Forms is a framework designed for an elite group of highly qualified professional web developers. You heard me. As I said earlier, you rarely do the simple examples you find in books right? So now you do something serious but you will always encounter a problem. Always, if you're not a well trained and highly qualified Web Forms developer as I said. Not problems related to HTML/JavaScript, the HTTP protocol, but the framework itself: how do I do that? how can I bypass that? why does I have this result? Why I have this meaningless error message? In what page event I should put this? How can I track this JavaScript error generated by the library? Why? How? Please kill me? I'm sure you have your load of examples.

Like I said, not every web developers, webmasters, HTML integrators knows Web Forms (and for some they shouldn't have to), but we all have a thing in common: we know HTML. Let's take this hypothetical scenario for a fairly beginner web developer that decides to use Web Forms: First you have to read your 800 pages brick. This is not enough you have to read articles each time you encounter a problem. One requirement of the application needs a custom control because it doesn't exist in .NET and is fairly wicked. You have to hack a little your control and have to learn JavaScript because it does some animations client side. You have problems with the generated client IDs. You also realize that the HTML generated from a component in the control enters in conflict with the CSS provided by the HTML integrators (they did it first on a plain HMTL page). Now that everything looks good some values doesn't show up on Postbacks. You read articles on custom controls. Your Postback finally works but your manipulations server side doesn't seems to be taken in account unless you refresh a second time the page. You read your book again regarding Page Events.

At the bloody end, you realize that you've spent most of you time fighting against the freaking framework and not on focusing on your goals. Let's take it from the start again, pens in hand. Web Forms tells you: "hey, we're so cool you won't have to do HTML nor JavaScript". You take that for granted and start learning for 90 days, you do the project above, you finally learn JavaScript for 30 days because the framework won't do everything by itself. You also read on the HTTP protocol (clients/servers requests/response, headers, etc) and debug in the Firefox console. Another 30 days. In the end you ended up learning every areas of web development. So why don't we do our things like grown ups from the start? Why don't we pick a slimmer framework, suited for the web, easier to learn, and at the same time we learn the nuts and bolts of all the remaining areas of web development? I guarantee you, if you do that you can't loose. Plus, if you call in the next 30 minutes.. (joke). Seriously if you do that, whenever you change frameworks, you still know the basics that "never" changes: HTML, JavaScript, HTTP Requests/Responses, AJAX, jQuery, etc... Isn't that pathetic, those are the things Web Forms don't want you to know.

The .NET Model View Controller (MVC)

Background

(disclaimer for the next 3 paragraphs: I know that MVC has been around sooner on Ruby on Rails than .NET. Just put all the MVCs in a bag and pretend that I'm talking about all of them at once)

I once heard something really hurtful (at that time) from some smelly game developers: "Web developers are not real programmers". Sure, I've come across many lazy web developers because I feel web development is more accessible for the mass (I'm sorry). Sure with some time game developers can do web sites on their own and I know that the other way around is not necessarily true. But in 2K, I must admit that it was nonsense (at least for me)... no methodologies, no structure, no real code reuse, no architecture. Anybody could do a website. The only goal was to deliver as fast as you can and be paid as low as they can. After all, web is easy. Our profession has since matured because we sat down to think of it (excluding myself in the "we").

I think technologies and concepts had a role in the transformation of the web site creation process. Since the web is a matter of requests and responses, I think that nobody saw the necessity of having a big set of object-oriented objects to be instantiated and connected together to deal with the business rules knowing that 10 milliseconds later it would be destroyed at the end of the request. It was hard to follow the "regular" design principles without doing some kind of over-design when applied to the web. So with time some concepts appeared that were more and more suited for the web.

So... where am I going with all this? I think MVC is one of the concrete symbols resulting of that needed change. To me it's not just another comparable features by features framework. It goes beyond that. It has history behind it and it acts as a proven point when I say that it was nonsense back in the days. The form to join my sect is at the end of this article. Just kidding, but seriously, the web has more and more of its share of design principles.

MVC's Foundations

The .NET MVC framework's name comes from the name of a design pattern. It is already more reassuring than Web Forms isn't it? MVC stands for Model View Controller. Essentially, the goal is to isolate each letter so that development, testing and maintenance can be done independently from one to another (Model–view–controller From Wikipedia, the free encyclopedia). MVC is more than that (since above is a description of the design pattern itself).

So how is MVC so great? Instead of swimming against the wave like Web Forms, MVC just goooo with the flowwwww. Remember that I've said that the HTTP protocol was all about anonymous (almost) requests and responses? Well MVC is all about requests and responses too. Each request that can be made to the server correspond to a method of a class. If the method has parameters, it means that the request (either POST or GET) must provide those parameters (if the parameters are mandatory, of course). And passing those parameters in the HTTP protocol jargon simply means submitting forms or using the query string. And they lived happily ever after. -END

I'm kidding but it's almost that simple! But how do I know which URL correspond to which method of a particular class you may ask? Well, lets put names on what I've been talking about. The methods are declared in classes: those classes are the Controllers. And those methods I've been talking about are called Actions. So each Controller have Actions. There's a built-in URL rewrite mechanism that makes a mapping between the URL and the Actions in the Controllers. The actions are free to return json, HTML, etc. So you see its suited for today's needs.

I don't want to go in details because this is not the main purpose of this article. But just remember that you have a bunch of methods in some classes and each methods usually correspond to a unique URL. Requesting an URL will call the appropriate method which will return you some content. You have no page life cycle, you don't have a View State, you don't have server side controls, you have simplicity. Let's see how it compares to the flaws of Web Forms.

MVC versus View State

There is no View State in MVC. If you use straight HTML, nothing will automagically retain its value if you submit a form back to the current page (the text in the text boxes will be gone). To have the values retained you can use "helpers" in the aspx pages:

<%: Html.TextBoxFor(m => m.UserName, new { style = "margin:10px;" , size = 12 }) %>

The HTML generated will look like this:

<input id="UserName" name="UserName" size="12" style="margin:10px;" type="text" value="" />

Wow no HTML clutter. But wait a minute you may say... aren't the aspx pages are hard to read for non-developers? Just like you told us with Web Forms? Yes I agree that's a new syntax. But it's a syntax only used for forms generally. Besides, the attributes given near "[...] new { style = [...]" are a 1 to 1 match with the HTML attributes. So the CSS guys can still use the real attribute names for their HTML elements. Also, if your receive your CSS in advance, prior to coding a form let's say, you know that the HTML generated from the helper won't be coming from outer space. The CSS guys won't have to comply to the framework anymore (but it's now the other way around, like it's supposed to be).

MVC Versus Controls

There are no controls per se in MVC. There are user controls. But again not built-in. You have to do the job yourself or have a look at the jQuery library. It means that you have full control (no pun intended) over your HTML. Look at a portion of a MVC aspx page:

<script src="<%: Url.Content("~/Scripts/jquery.validate.min.js") %>" type="text/javascript"></script>

<h2><%: ViewBag.Message %></h2>
<p>
    To learn more about ASP.NET MVC visit [...]
</p>

Woah it's 1999 again in your head... there's a server tag in the script's src. Yes for you it's a step back and it makes you think about your classic ASP programming. But remember the view isn't tightly coupled with the controller. There's no way to initialize or set-up your view other than that. The only thing the controller gives you for your view is a bag of informations. That's a good thing. Plus, you have complete control over the HTML generated, over the JavaScript, over the CSS, etc. Go create an MVC site and tell your friend to do "view source" on your site's homepage. Some will believe that it's a static website in plain HTML. It's that clean.

But, isn't it a tedious task, editing the aspx page this way? Ok I'll answer one last of your questions: No. Remember all the books you bought to learn Web Forms to finally have to learn JavaScript anyway to get lost in their endless libraries? Well buy an HTML book, a JavaScript book, a jQuery and CSS book from the start and do MVC. You'll end up being much more productive because remember, you never do easy examples as in books. And the knowledge you gain, you put it on something useful. Not a dying framework. That's still good for your career if by any chance you stop doing MVC. Plus, there's plenty of jQuery goodies out there. Trust me don't be worried.

MVC Versus Page Life Cycle

Since the request hits a method server side, there's no page life cycle in MVC. So no surprises on what gets called first or what gets initialized first. (wow short section)

Last Words on MVC

I didn't go in details as you can see and there are probably more questions rising in your head than before reading this article. But that's the point. I'm here to shake you up a little. MVC is a slim, to the point framework that puts the emphasis on a good architecture. Sure it's up to the developers but at least when you create a brand new project, the folders are well organized to give you some kind of directions. Not only the aspx code is cleaner for everybody, not only the resulting source code is cleaner but also the urls are cleaner. Being RESTful, they're great for indexation and bookmarking.

Now you go learn MVC to see what I'm talking about!! To give you an idea of how easy and fun it is, I have read around 60 pages of the book
to get started in only an afternoon to do professional sites with MVC (when it was in beta stage). You can do it too! There is a new version of the book available and this is all you need to do amazing .NET MVC sites in no time.

Conclusion

Today, it's not everybody anymore that can do websites at the level we (web developers) do it. It's a complex game, you can't hide and pretend it's something else anymore. If you have to spend more time dealing with a framework than actually doing your application, you have problem. A problem we often have with Web Forms.

Maybe web development is still rather new and we're just beginning to see real object oriented concepts applied to it to solve problems for what they are. But still, it becomes more and more mature. In the end, we're maybe not calculating tangent in our day to day lives but personally, doing simple things well is harder than doing complicated things well. It's up to us to make web development better, as simple as it sounds.

Next Steps

As I said earlier, I've read 60 pages of a previous version of this book () to get started using MVC! It is that easy. I can't recommend you enough that book and I can't say it better than amazon itself: "The book's authors, Steve Sanderson and Adam Freeman, have both watched the growth of ASP.NET MVC since its first release, with Steve taking a particularly prominent role. You can be sure you are in safe hands."

Related Articles

• IoC Containers With .NET MVC - Understand Current Ones by Building your Own
• StackOverflow DevDays - (Talk 1 of 6) .NET MVC

See ya