@Phil: Turn off Central Heating
Please read Phil's post to determine if MVC is Right for You before proceeding.
Phil On MVC:
"It's true, MVC is not the model for people who want the freedom to be creative with their code. It's the pattern you follow if you want to conform with a particular doctrine of programming. There is (if you follow it to the letter of the law) not a huge degree of flexibility."
"That's the theory anyway. In reality, you as a developer can still put code in the wrong place, you can still make bad decisions on how to structure your application and you can still essentially cock the whole thing up."
I'm confused, with MVC am I forced to write one way or am I not?
Phil On WebForms:
"With Web Forms as a developer, you're pretty much free to follow the path which suits you best."
"I strongly support the Web Forms model and believe that the majority of the flaws in Web Forms that MVC purports to overcome are easily solvable by following the guidance and advice of experienced ASP.NET developers."
"Those of us who have been building ASP.NET professionally for years are now in a position where it is easy. We have our pattern to follow and we know how to build good maintainable ASP.NET applications."
"Structure and form becomes an integral part of our Web Forms applications."
If you are an experienced ASP.Net developer you write WebForms with the same pattern as all of the other experienced developers. So, I can write WebForms following any path that suits me best, but in reality there is only one best path.
It's the Convention Stupid
MVC is all about conventional web development. By convention, your code is logically split into three categories: Models, Views, and Controllers. By convention, your Controller has one or more Views and orchestrates the interaction between users and business logic. By convention, a Controller action will render a View with the same name as the Action. By convention, Views contain only rendering logic. By convention, Views are stored in a folder with the name of its respective Controller. By convention, that folder is stored in a root folder called Views. By convention, layouts (master pages) are stored in a folder called Layouts. By convention you flame anyone who talks bad about MVC.
I am three weeks from releasing a medium sized application written using MVC. Guess what, I needed to store my Views in a folder that wasn't called Views. So I broke convention. My framework of choice supported the ability to change this convention. I broke several other conventions in the course of development. When you say that "There is not a huge degree of flexibility" with MVC, that is complete FUD. What you meant to say was that the framework you are using to achieve MVC has limited flexibility.
ASP.Net has the same concept of a convention, it's called Patterns & Practices. I only wish this convention had preceded the release of ASP.Net, rather than being born years later out of a prevalent lack of "guidance and advice of experienced ASP.Net developers."
MVC Makes Testing Your Applications Possible Easy
"I'd agree testing is hard with Web Forms. In fact, I found it so difficult I abandoned trying to unit test my ASP.NET code and moved to a process of using Watir and testing the rendered HTML instead."
Phil postulates that less than 1% of all .Net developers unit test. I will give him the benefit of the doubt and interpret this to mean that less than 1% of .Net developers unit test non-business logic code. He goes on to say that it's great the MVC makes this possible but it doesn't really matter because people who didn't unit test before will not unit test now. Phil, did you ever think that the reason that ASP.Net developers do not unit test their code is because it is so difficult they choose to abandon it? Perhaps if it were simple and straight forward and part of the guidance and advice of experienced ASP.Net developers, that number would be higher? Just a crazy theory of mine.
Learning Swerve
If you are designing a serious web application using ASP.Net, you better know the Page Event Lifecycle forwards and backwards (the overview alone is eight (8) printed page). You better be intimately familiar ViewState, SessionState, Server Controls, User Controls, and INamingContainer. You better be causally familiar with the Application Event Lifecycle. Don't even bother trying to use rich third party libraries like Prototype or jQuery, unless you want to write ASP.Net wrappers for everything. But oh yeah, you can use MS AJAX for all that. Better put that on your intimate familiarity list too. Unless you are writing an online guest book for your mom you better know your stuff.
Phil really pushed my hot button with this quote (I do not know if these are his words or if he is quoting someone else):
"Programmers more than nearly any other demographic, despise change. Programmers not only despise change, they run from it and tell other people that change will kill them as they trample innocent bystanders."
HELLO PHIL! ASP.Net was the single largest changes to web development since CGI. We went from writing HTML with classic ASP to a complete freaking object model for everything down to Literal text. So don't spout this FUD about trampling innocent bystanders. Don't cry to me because you feel you've wasted years learning about ASP.Net and that it doesn't apply to MVC. Maybe if you had studied HTTP and HTML instead of this leaky abstraction that attempts to 'simplify' and already simple protocol, you'd be in a better position today.
I will admit, to be effective with MVC, you must be comfortable with HTML. HTML, that is HyperText Markup Language. Are you familiar with it? It is relatively new, only came out about 25 years ago. I think they start teaching it in elementary (primary) school nowadays. If you aren't familiar with it, luckily:
"With the mass of technical articles, blog posts and snippets out there around HTML ASP.NET Web Forms one other great advantage is that almost any problem you can face with HTML ASP.NET will be documented and the solutions listed somewhere on the Web, it's just a matter of searching for them."
What is the first thing you learn in a programming course? Variables, flow control, and loops. Combine those three concepts with an understanding of HTML and you have 75% of the knowledge necessary to create a user interface using MVC. Next you will learn about functions and maybe an object. If you can write an object with a function then you can invoke an Action on a Controller. The curve doesn't look so steep now does it.
Control Over your HTML and JavaScript with MVC
This seems to come up a lot in discussions about MVC. We always spout off about separations of concerns and such, and somebody points a finger at code in your view and says "..the separation of markup from code is completely disregarded as a non issue." It is disregarded as a non issue because it is a non issue. Just because your asp:GridView and asp:Repeater represent code via XML doesn't mean you aren't mingling markup and code.
Let me leave no room for confusion: your View contains view logic. This is again where Phil misleads you by saying MVC leaves little room for flexibility. Some people like to design their Views with absolutely no logic, the Controller does all of the thinking right down to the color of a table row. Others like the Controller to specify the logic (line item 26 is backordered) and let the View handle the presentation (if lineItem.IsBackorderd then tr.BackColor = 'Yellow'). I personally subscribe to the latter but the flexibility is there for you to choose what works. And as I mentioned before, have fun integrating something like jQuery with your ASP.Net app.
In Summary
Use What Works. If you are happily developing with ASP.Net and it causes you no pain, then there is absolutely nothing MVC can offer you. I have developed ASP.Net applications. They have caused me pain. I chose to explore other options. I find myself more productive with MVC. If you had developed those same ASP.Net applications, you may very well have not felt the pain I did and would happily continue to use ASP.Net. Use What Works.
Do not attempt to say WebForms is better than MVC or that MVC is better than WebForms. I have not attempted to say that MVC is better than WebForms in any respect (with the exception of unit testing). I have vigorously attempted to counter the FUD from Phil's article.
I find that MVC Works.
@Phil: Turn on Central Heating.