In our current iteration of improving our software development strategy, ASP.NET WebForms simply doesn’t fit in with the new demands of being unit testable and flexible. It comes as no surprise that ASP.NET MVC has been getting all the headlines lately. Like many others, I’ve gotten the itch to try it out. In this post I’ll talk about what I believe are the main pro’s and con’s of the new style for building web applications.
PRO – No ViewState or "surprise crap"
In traditional ASP.NET WebForms, the luxury of pretending to behave like a Windows Form comes at a price. The ViewState is a reliable way of storing all of the state information for the form. Unfortunately, due to the limitations of the web, this data needs to be a giant string inside of a hidden form field. This ends up adding a substantial number of bytes to the page, making it slower and requiring extra bandwidth. Of course the ViewState is controllable, much like the dinosaurs in Jurassic Park.
Not only is the ViewState gone, but "mystery" generated HTML is also gone. You have strict control over the HTML. This gives you great power, but with great power comes great responsibility. Use it wisely, and you will have elegant XHTML output with no surprises. You need to really know your HTML, which in today’s web world is a prerequisite anyway.
PRO – Faster server-side
It’s hard to get any real performance data about MVC, but it’s been suggested that it’s potentially 8000 times faster. Supposedly it’s due to less processing since it simply processes a "template" instead of having to build a complicated control tree. Even if it’s twice as fast, or even marginally faster, that would be significant for popular sites, or give at least a slight boost to smaller sites.
PRO – Simplified model for multiple related views
One thing that I found much easier to do with MVC was to have multiple versions of a page that displayed the same data, but in a slightly different format. For example, on my RSS package tracking website, you can look at your tracking information in a full-featured desktop browser, a mobile browser, or an RSS reader. The data being displayed is always the same, but the actual rendered output was different. If I later want to make an iPhone specific version for example, I would simply make a new view, and use an existing controller action.
PRO – Unit testable
One of the biggest challenges with WebForms was that testing was difficult. Not only was the actual output not easy to test, but the code-behind would tend to be a place that would contain important code that would never get unit tested. With both MVC and WebForms, it’s best to keep your logic away from the page, but it’s not always easy or ideal. MVC makes it simple to unit test the logic that is specific to a page. To do so, you simply test the actions in your controllers, which are regular, easy to test classes.
CON – Difficult to convert an existing site
MVC is not only a framework in this case, but a style. It is possible to convert specific pages as needed, but the cost is high. The problem is that MVC is radically different, so the benefit of converting probably isn’t worth it for most of your existing pages.
If you decide to convert your site to MVC, you may also run into issues trying to maintain existing page addresses. The specific issue I’ve ran into is that routes cannot have a trailing slash. If you want to maintain existing URL’s that have trailing slashes, there is no way to have the built-in routing generate URL’s with a trailing slash. You may end up losing one of the big advantages that MVC has to offer.
CON – Not best for SEO out of the box
I’ve mentioned some of the SEO issues before, and all but the trailing slash issue have a reasonable workaround. The routing engine likes to allow multiple addresses to render the same page, instead of enforcing a single address for each page. Luckily, as Scott Hanselman mentions, you can use a URL rewrite engine to bend it to your will. I highly recommend spending some time writing intelligent rules that perform the necessary 301 redirects, because you don’t want to take chances with SEO (Search Engine Optimization).
CON – Challenges if you’re not running IIS7
It’s clear that the last couple of versions of IIS have been major improvements over their predecessors. IIS7 takes .NET integration to an entirely new level. There is already a good page that covers the challenges you’ll face if you’re not running IIS6. I’ll just list them here for brevity:
- .NET needs to handle all page requests to ensure that the MVC pages will be processed. This leads to bad performance of static files.
- HTTP Compression through IIS6 doesn’t work, because the MVC pages are dynamic.
- The homepage gives a 404 when hosted on the root of a domain.
Summary
If I needed to build a new site from scratch, and was able to use IIS7, it would be extremely likely that I would choose ASP.NET MVC. It’s a joy to work with (possibly because it’s "new"), and just makes sense. If I needed to work with an existing site, I would certainly have to consider the pro’s and con’s I mentioned above. ASP.NET MVC gives us an amazing new tool in our huge Microsoft toolbox.
MVC has also another con :
You will write more code and the view code reminds classic asp code.
Pro:
You will write more code because you should write tests for every method.
Rodrigo, you don’t have to write tests, it’s up to you. It’s an opportunity, and not a cons. Classic ASP is different from MVC Views. Views are just presentation, it’s not necessary that View should generate HTML code, as mentioned, it can be RSS or a mobile application code. So I would consider it also as a great opportuninty.
8000 times faster? I’d be interested in hearing where that came from…
I wrote an article that compares Silverlight vs ASP.NET MVC based off of your pros/cons and some extra items I added in there:
http://www.silverlighthack.com/post/2008/10/23/Silverlight-ASPNET-MVC-vs-Web-Forms-(Very-High-Level).aspx
I don’t think it’s fair to use “conversion” as a CON in this case. It’s not MVC’s fault if you decide to switch in mid-development in the same way that jumping from one car to another on a freeway might be hard
.
With respect to SEO – your examples about duplicate URLs are again not MVC’s issue – they’re yours. MVC is a very developer-friendly toolset and yes, you can step in some poop. It goes without saying that you really need to be careful with your URLs and NOT allow duplicate paths. See what Stackoverflow is doing – Jeff’s getting amazing SEO uptake.
I do agree that some work is required to get it running on IIS 6 – that’s unfortunate. You don’t need to route every request through .NET, however,
and Scott touches on that here:
http://www.hanselman.com/blog/DeployingASPNETMVCOnASPNET20.aspx
Finally finally
– Rodrigo you only write more code in the View if that’s what you’re into. Every page I’ve written (see the MVC Storefront) has about 70% text reduction in the View – this is because there is not markup from controls on a page.
Rob, the duplicate path issue has a decent solution.
What does NOT have a decent solution, and what everyone seems to ignore, is that you cannot have MVC GENERATE a link with a trailing slash. This is because if you have a route defined with a trailing slash, MVC internally drops it when storing it to the routing table. If I want to convert an existing site that has trailing slashes, I have to drop the slashes, or hard code all of my links.
I apologize if I haven’t done a good enough job explaining it. The fact is that I have a site in this situation, and my only solution right now is to hard code very link, which I’m hesitant to do, because I’m hoping that there will be a more elegant solution at some point.
As for Jeff is not converting a legacy site, so he can come up with whatever URL scheme he wants. On any of my new projects, I’ll happily live without the trailing slashes.
The 8000x figure is a bad case of the telephone game!
Here is the source:
http://forums.asp.net/p/1231621/2224136.aspx
It’s partially my fault as well since I switched it from “8000 requests/sec” to “8000 times faster”. I screwed it up.
Anyway, I’m confident that it is faster, there just isn’t any real good data yet. If speed is at the top of your requirement list, that’s a point for MVC.
I am guessin thtat devs that grew up in RAD environments (PB,VB6, delphi etc) are going to see this as a step backward in having to generate all the html for controls, input boxes and the like that more or less gets handled for them in forms development yes?
Developers that rely on auto postback to ease data entry for end users are probably in for a bag of hurt with this technology.
Mike, it depends what you’re doing. There are helpers that minimize some of the tedious work. However, there are certainly scenarios where I would probably just go back to standard webforms. The true test will be to see what I tend to do once I am equally proficient with both.
Hi rob …You do write more code using the mvc and thats a fact, because you don’t have to write the webform controls markup… you use drag and drop.
The code is a lot cleaner with the mvc and you do have less markup, but you have to write it without the help of any tool.
For me personally, the greatest pro as well as the greatest con for the ASP.NET MVC framework is the fact that it hasn’t been fully flushed out yet.
That is, there isn’t an agreed upon way to do things. This is great in that it allows you to implement features in a way that makes sense for you and your application. But it’s also bad in that it greatly increases the learning curve and might make adoption of the framework a hard sell.
As an example, the ASP.NET web forms model has an easy to understand and easy to implement procedure for validation. The ASP.NET MVC framework…not so much. There are plenty of custom solutions out there which are arguably better than the ASP.NET web forms validators in that they allow you to hook into database events and put validation on your model instead of your UI, but again it comes at the price of ease of use. I can see developers being very reluctant to have to research and develop custom solutions for things that normally come out of the box in development frameworks.
I’ve written VoiceXML applications using Classic ASP. It is stupid to think Classic ASP can only output HTML.
Thus, MVC is more like Classic ASP/PHP than Webforms.
I was wondering in what kind of trouble one gets into if considering to deploy a .NET MVC application on linux with mono… my guess is in the end you have another con (at least for a while) :/
I love webforms!
> It’s partially my fault as well since I switched it from “8000 requests/sec” to “8000 times faster”. I screwed it up.
Why not fix it in the post? I happened to the read comments but most users won’t and you are grossly misrepresenting the facts and misdirecting the readers.
“…WebForms simply doesn’t fit in with the new demands of being unit testable …”
That is just not true. Just look at the post by P. Haacked on MVP Supervisor:
http://tinyurl.com/of7rm
ASP.NET MVC is really good, but you can’t use TDD as a pro over webforms development.
MVC is an improvement compared to classic asp.
It offers a better framework to put everything in.
Compared to asp.net it has it’s drawbacks.
Re-inventing the wheel is one of them.
Dirty asp-like spaghetti-code is another one.
The thing I especially don’t like is that while asp.net uses an object-oriented approach to the controls (server controls), MVC has gone back to procedural controls (html helpers).
And for me this is a step back in software design.
Many things are no longer strongly typed and error prone.
I’ve used MVC for a while now and frankly it’s been a disappointment.
While it has it’s uses for some things, for standard web-applications we will be going back to asp.net.
Nice Short and Sweet Comparison, similar comparison for MVC vc Silverlight is welcome
I programmed a site in asp.net, and what annoyed me the most was the tens of events they put on a page (pre_init, page_load, render..etc).
asp.net has got some convenient tools, but if you look deeper, you will see that it has got a lot of complexity, all that object generation, event binding with event handler methods, data controls are nothing special..
I develop using php right now, and I can tell you that its controls dont add much..There are too many tools that were put that dont add that much. Caching & dataset (all ado.net) might be useful in some specific sites..but they arent critical to use..you can use connected data transfer, and it works well!!!..
I had a look at mvc, that introduced the idea that you can generate html using functions (controllers), and unit testing, and friendly url, and no viewstate… but wasnt mvc inspired from ruby on rails? (thats what I read at least)..
I think that all asp.net is too convuluted.. I would rather to go to and stick with php. Asp.net tries to revolutionize the web development, but it never adds something new and revolutionary that is significant.. a language like php that has no tools like asp.net is still alive and kicking,,and no new gimmicks from microsoft will kill it..
http://forums.asp.net/t/1488120.aspx/1
Please go through the link…Is there any truth?