MVC is an apt pattern for the web. It fits it much more nicely than the leaky abstraction of a stateful platform on a decidedly stateless protocol. This breaks down quickly, and you spend more time dealing with issues relating to this leaky abstraction than actually writing for the web, which is what I think we should be doing.

ASP.MVC doesn’t support server controls, but it does have a ton of flexibility in how you compose a view.

The web isn’t the desktop. We shouldn’t pretend that it is, and we shouldn’t write applications as if we were running on the desktop. Program to your platform, and you’ll reap the benefits that it has to offer. Put on rose colored glasses and pretend that you’re writing for the desktop and be certain that you will face performance and/or usability problems along the way.

ASP.NET MVC is a back-to-basics platform that takes a few key things right to its core:
* testability
* single responsibility
* full control over URLs, HTML, CSS, Javascript integration
* easier ajax integration

Lastly, also consider that ASP.NET MVC is still in its infancy. There are rough edges, sure. But it’s a breath of fresh air in comparison to WebForms, in my opinion.

WebForms does a reasonable job of abstracting the Web away for development, and that’s it’s strength and weakness. To make to best of the web you really have to embrace it.

MVC allows for TDD, WebForms is a pain to test. Even desktop apps could benefit from an MVC approach.

That being said, MVC is a reasonable way of organising your project if:

* You must follow a graphic design from a designer which is delivered as HTML+CSS.
* Your forms are simple and don’t need complex UI controls.
* You are creating a page based form for a web site.
* You just want a step up from the tradional PHP/ASP/CGI style of request/response programming.

But don’t try to make applications using MVC. It doesn’t offer the support you need.

I still do believe controls are great. Why? They are as complex as any Markup Language is. An old colleague of me ever told me that a Domain Specific Language such as ASP.NET is as complex as the domain itself.
I don’t see how this could be made easier with the MVC model. I only see a lot of work for getting used to the pattern, a lot of less readable code(be honest, stuff like attributes above methods are not pretty and easy to understand). And beside of that, MVC is only interesting to use when you’ve to reuse the data very often. Otherwise writing or generating Model, Controllers and Views are just to many steps. The form support itself is ridiculous, for those circumstances you need a control model. Or maybe you should generate a Model for this once again?! That would mean that instead of making stuff easier, you’re just generating more and more code. Which does make your codebase more complex. Especially because the generated code is the place where you want to add your business logic.
Beside of that, how do you guys think about generating forms on the fly? Ever heard of a changing Model on the fly?

Jukka-Pekka makes it even more interesting. Yes I’m sure there will be a future for CMS’s. In the world of CMS’s there’s a general bigger challenge then just techniques. This challenge is called ‘organizations’. Simplifying processes, making marketing people more effective, etc.
When you look at it from a technical perspective, so far MVC has only been working with database date. Typically Microsoft. MOSS is also only database data. Texts and blob. But there’s way more in this world. For example relations between content, either impliciet(taxonomies) or expliciet(e.g. links in content). And as long as we’ve to help people in making technical stuff usable for the end-customer, there will be a challenge for CMS Vendors.

- Alex

One thing is intresting though, if MVC on .NET has remotely same effect as Django and Rails is forming on the “other side”. What will be the future of CMS like Sitecore?
I don’t see how MVC and Sitecore (or any other CMS) can work together do you?

Not to mention having to memorize the lifecycles to begin with.

This seperation also allows for a more REST based approach, where resources are available in different formats (think SOA and web services) and the requested view drives what is delivered to the requesting client. Routes are also clearly seperated. You know longer hit “pages,” you hit routes.

The focus on the model (even more so, the domain model if you take a DDD approach) over pages and controls is important to me. It’s tough to dig through lots of page cycle events before finally being able to request something from the domain.

And yes, testability, but more so TDD and BDD where you start with the tests (or specifications) and drive your implementations from those “requirements”.

As far as controls based argument, I think ASP.NET probably has MVC beat currently, but that might change soon enough?

2 cents. Thanks.

Controls make great demos – Microsoft has been demoing dragging the database and displaying the Northwind database before I even knew I wanted to program. However in real applications you always end up hating that dragged datatable.

This might not be the best argument, but look at the popular web frameworks in other languages: php, python, ruby, java – they’re on to something.