There is a bit of turbulence in the ASP.NET airspace over MVC (yes, I'm making this post while on the fight back from the ASPInsiders Summit). Even among the ASPInsiders, who are supposed to be at the cutting edge of ASP.NET, there is little agreement over what is MVC and what it's for.
MVC, or Model View Controller, is an age old pattern found in many places. ASP.NET providers follow the pattern, as does Service Oriented Architecture. The general idea to have some code called a Model that works with your data storage, other code called a View that displays the data, and last plumbing code that ties these two together, called the Controller. I call it a pattern because implementations differ in the details - the View may render a button, but when the user clicks that button should the click action be handled by the View or Controller? The Model and View should know nothing of each other, but is the Controller allowed to be tightly coupled to them both? (If your first thought above was the Controller should handle the button action, think now what this means about being loosely coupled between the View and Controller).
ASP.NET MVC is a framework in development that is intended to closely match the MVC pattern. The minefield lies in answering the pragmatic question of what does ASP.NET MVC offer over WebForms, and when would you use MVC? In taking with those excited by MVC the reasons range from supporting TDD, clean URLs and avoiding postbacks by sending actions to a controller, better control over HTML output (including getting rid of ViewState), and being closer to the http protocol.
TDD, or Test Driven Development, will always come up in any ASP.NET MVC conversation, but TDD itself isn't an explicit part of MVC. The MVC pattern is very amendable to TDD however, and thus the association. I generally support testable code even if there are no tests around the code. Testable code is much easier to maintain, enhance, refractor, and replace. I don't find the process of test-first development helpful, but I do write tests in the same session as the code when I know I'm writing some critical piece of functionality that needs to survive multiple versions of the software. As Hanselman noted, I'm like the "person who goes to church on Easter and Christmas" and I'm sometimes looked down upon by the congregation who attend weekly. I'm okay with this, but I have some reservations with MVC as a framework for TDD.
WebForms provides a very robust SiteMapProvider interface that makes it easy to clean up urls of dynamic content. Global.asax can be using to control routing of requests (in fact this is how MVC does it as well). The biggest problem I've had here isn't WebForms fault, but IIS6's inability to allow ASP.NET to handle requests without an ASP.NET extension in them: this is solved in IIS7.
The last reason for MVC I mentioned, being closer to the http protocol and its stateless nature, I simply don't grok. Any application with a basic level of user interaction will need to mask the http protocol's implementation details to provide a positive user experience. Web programmers of all frameworks and languages have realized there are only a few methods to solve this problem; cookies, url parameters, and hidden fields. Any state solution will involve one or all of these - even if state is stored on the server's side. WebForms supports all of these methods, and you can disable things like ViewState (hidden fields) if desired. (I am aware there is also ControlState that will be still emitted if ViewState is disabled, but I'm willing to say that if these few bytes are an impact you are working on an edge case).
I'm not here to bash ASP.NET MVC - to the contrary I'm here to help by outlining the faults in the current arguments for MVC. If MVC is defined by the features in or not in WebForms, then it's going to be hard for those deep into WebForms to see value in MVC. It becomes a song of "anything you can do, I can do better (no you can't, yes I can)" and will deadlock when neither side is listening to the other. ASP.NET MVC need to be defined without claiming faults in WebForms, because that only says use MVC because WebForms is broken - leading one to say, "why not just fix WebForms?"
I wish I could end here with a new explanation of ASP.MVC meeting the requirements I've just stated, but I'm afraid I can't. This is a fault with me, and not the MVC framework - I'm too close and deep into WebForms to see a need for MVC I can't fill already. It's my hope and request that instead of seeking to pick apart this post, the supporters of MVC come out to define MVC without attaching that definition to the perceived faults (for that's the minefield) of WebForms.
This is a great post!! I'm totally into your reasons (and very good ones) for the "why of MVC"? I will have a follow up post that I hope will shed some light on why "I think" MVC is a good change for ASP.NET
OK, I have to admit that I don't know much about MVC besides watching a couple of videos here before I say anything, but here goes.
I'm definitely of the same mindset about testing--test the model and you should have most everything covered. (If not, you're probably doing too much in your UI that you should be doing in your model.) But some people want to test more, and that's OK.
I like the concept of MVC because I like being closer to the HTTP protocol, as you say. It's probably because I was so rooted in PHP and Python/SnakeSkin when I came to ASP.NET. Those templating systems are very procedural (as MVC seems to be)--take X data in your controller and output Y code with it in the view. ASP.Net, on the other hand, is more declarative--here is data source X (defined in the view!), use it to fill in web control Y. It's a different way of thinking, and one or the other is more natural to some people.
Yes, that means you're taking a step backwards if you use MVC. You don't get all of the nice features like ViewState and Sitemaps and such, but I imagine there will be Microsoft or open source projects that will fill in the gaps, should MVC take off. Personally, there are a lot of features like Sitemaps I've never used--they seemed a little overly complicated for what I was trying to do. So unless you absolutely need one of these features that MVC doesn't have, why not use MVC?
It's a question of the right tool for the right job. I'd rather have a low-level tool like MVC (well, ok, Python/SnakeSkin) when developing a plain old website, because it lets me get closer to the HTML and design the interfaces I need without having to figure out how to manipulate WebForms into doing it. It also makes it much easier to host, but I suppose that's a different story. But if I'm writing a web application, ASP.NET gives me the ability to write my model in .NET (useful if I need to use it anywhere outside the web app), and good tools for building an application.
My point is, MVC itself doesn't really need to be defended. It's just another way of doing things, and frankly, I think it's a smart move by Microsoft to provide support for both approaches. It shows they're listening to developers and trying to provide the tools they want (which, yes, admittedly does get into "embrace and extend" territory, since there's been several tools like MVC on the FOSS side for a while).
The real issue is going to be whether people on either decide that their way of doing things is the One True Way no matter what the usage. Whether you use MVC or ASP.NET should be a question of (a) the client's requirements, (b) the right tool for the right job, and (c) the skillsets and preferences of your programming team--and by that I mean a consensus of what they're comfortable with using. If people ignore those things and push for MVC when--for the sake of the project and their team--WebForms would be a better choice, then you have a problem.
The issue isn't whether MVC has its uses or not, the issue is whether it becomes overhyped and faddish.
Enjoyed this one. Writing like this showcases the fact that you've been reading well-written stuff. :)