Last year at the fall 2008 DevConnections conference, I was very happy to hear Scott Guthrie providing a clear message about web forms vs. MVC in ASP.NET 4.0.
Now, I am seeing something that is new for MSDN Documentation, not only similar clarity but actual guidance on when Microsoft suggests to use one over the other.
You’ll find this in two places.
First, in the ASP.NET MVC Overview topic. In this document, their is a list of advantages of MVC and a list of advantages of web forms apps.
Next, in the topic titled Compatibility of ASP.NET Web Forms and ASP.NET MVC, there is a short list of strengths of web forms and another of the strengths of MVC. Following this are short lists of asp.net features that are compatible with MVC and then those that are incompatible with MVC.
Key from the overview doc:
Line of Business web apps
- Web Forms “preserves state over HTTP, which benefits line-of-business Web application development.”
Web Forms for RAD and MVC for granular control??
- Web Forms “works well for small teams of Web developers and designers who want to take advantage of the large number of components available for rapid application development.”
- Web Forms “in general … is less complex for application development".”
- MVC is for “large teams of developers and for Web designers who need a high degree of control over the application behavior.
Test Driven Development
- MVC “provides better support for test-driven development (TDD).”
The bottom line?
There’s a way of reading the documentation that might cause you to summarize that Web Forms is for RAD development and MVC is for serious application development. Does that mean the line of business apps do not belong on the web because they require us to use session state and any web developer in his/her right mind would not want to incorporate session state in their applications? Well, the problems that pop up when you start considering session state on distributed servers suggests that the answer to this question is “yes”. But ASP.NET developers never really had an option before.
Remember that ASP.NET was created so that windows developers could write web apps, and that’s why things like session state and view state are so critical in web forms. They are potentially cumbersome to deal with and easily misused.
MVC goes back to a more purist form of web development which is state-less. But a stateless environment doesn’t lend itself well to having large units of work which we have gotten used to in LOB apps.
On the other hand, even the documentation says that you will have a lot more work ahead of you if you want to work with MVC. First of all, there’s a major paradigm shift from web forms, especially for those who don’t come from a web background prior to ASP.NET.
Where does this leave me?
This leaves me much more curious about MVC and thinking that I may shift my focus of attempting to design serious web app that use Entity Framework from web forms to MVC. It also leaves me nervous since it also might mean a major last minute change to one of my DevConnections presentations this week. It will be hard because leveraging MVC to demo another technology depends on the audience having a general understanding of MVC which is not something that I can expect at all. Now if my session were 4 or 5 hours long, it would be a different story.
Sign up for my newsletter so you don't miss my conference & Pluralsight course announcements!
Two comments:
1) Never ever change your presentation so close to the delivery. It is bound to go wrong. Stick with what you got and start doing the shift for the future.
2) LOB applications does not have to be state full. This is a miss-perception, the web is stateless and a lot of other stateless technologies outside of the .NET space have had a successful time delivering LOB applications. Look at salesforce.com for instance.
My sad conclusion with web forms is that it was a wrong turn. It was, as you say, intended to bring windows developers to the web, which it somehow succeeded in, but failed in delivering a framework optimized for web development. The MVC framework on the other hand is that optimized framework.
MVC + JQuery is very powerful in delivering LOB and any other type of applications you want to put on the web.
Oh boy…. there is so much wrong here. I’m not sure if it was your editorial of the MSDN stuff… or you were quoting what they said.
The web is stateless whether you use Web Forms or MVC. Unless you are writing a totally static web site you have to figure out a way to maintain state.
Web Forms abstracts this out into the session object. Let’s face it, session existed well before ASP.Net. I think the problem with Web Forms is that they make it to easy to abuse that abstraction.
I have seen this first hand. Developers using session to store datasets, to pass state data from one form to the next during a business transaction, etc. All these things are not a good idea. They really put a drain on the servers memory and that app domain start recycling all the time.
Viewstate is another abstraction that people rely on too much and abuse. It really bloats your web pages, which also stresses your bandwidth.
This is all why people say web forms is a leaky abstraction. However, you can use web forms and not abuse these things. Actually, I think asp.net 4.0 is actualy going to make this eaven easier.
I personally think the main reason to NOT use web forms is because you are giving up a lot of control of your web page and your markup. You have to resort to a lot of tricks to have it render the way you want and also to use client side code.
Now, when you use MVC for whatever you have a lot more control over the markup. Also, you have to be very aware of how you are maintaining state. I’m pretty sure you still have access to the asp.net session object in ASP.Net. But, there is no magic viewstate… there is are not server controls doing a lot of hidden stuff. If you want to save state you have to make a decision about where to store that state.
I think you can write an LOB application with MCV very well.
I don’t think it is state full vs stateless at all. I think the difference is control vs abstractions. At least I fell that this is the main difference between the two different web UI layers of web forms and MVC.
Julie,
It’s time that web developers ( particularly webforms developers) stepped up and learnt the basics underlying what they do – HTTP over HTML.
Relying on your web framework to provide the illusion of stateful interactions is (IMHO) a very clear violation of SRP, and with webforms this abstraction is very leaky.
Can I suggest you have a look at long running transactions, aka conversations, implemented with technology like NHibernate Burrow. These approaches make it very easy to work with what you refer to as "large units of work" across multiple requests while still working in a stateless environment.
Cheers,
Neal (@randomcodenz)
I wish I had better expressed in the post that webforms gives the "appearance" of state. Or perhaps that yes, I do in fact, understand that. 😉 There are devs who think that "appearance" is a reality and those are the ones who tend to unknowingly abuse the asp.net session.
If you want to use LOB as a demo then please concentrate on Silverlight – it makes more sense than either forms or mvc
I am a somewhat recent convert from web forms and mvc but have to say it is a great shift. Here’s to looking forward to EF examples with MVC!
This is a cool article on the subject <a href="http://ixtus.tut.su/articles/storage/Dino_Esposito_on_ASP_NET_MVC_vs_WebForms.html">http://ixtus.tut.su/articles/storage/Dino_Esposito_on_ASP_NET_MVC_vs_WebForms.html</a>
check this out
http://www.codeproject.com/…/ASP_NET_MVC_WIT