I just went through some MVC tutorials after checking this site out for a while. Is it just me, or does MVC View pages bring back HORRIBLE flashbacks of Classic ASP spaghet
The difference is that in MVC the only thing that the view is doing is rendering the display. All of the business logic, I/O handling, and model-related code is found in the controllers and model classes. The amount of code found in the view is relatively small and compact -- and you can abstract it out into user controls (partial views) if it is commonly used.
Personally, I like the extra control I have over the view. Most of my time with webforms seemed to be spent trying to work around the default assumptions that were made (and the name mangling introduced by master/child pages) that made it difficult to do much of anything client-side.
EDIT: I forgot to mention the ability to create HtmlHelper extension methods that lets you move a lot of the stuff into the backend as well. All in all, between the controllers, models, and extension methods it adds up to a lot more code that is easily testable in MVC that in either classic ASP or ASP.NET WebForms.
This was mentioned at PDC, they did mention it was a bit too "classic asp" like with all the <%=. But they also did mention that they will be adding standard ASP.Net tagging and controls.
The entire direction for them is to get a stable release, then make it easier to work with.
PDC Video: http://mschnlnine.vo.llnwd.net/d1/pdc08/WMV-HQ/PC21.wmv
see Jeff's post (http://www.codinghorror.com/blog/archives/001155.html) which echoes your question, and Rob Conery's response (http://blog.wekeroad.com/blog/asp-net-mvc-avoiding-tag-soup/)
In summary, ASP.NET MVC gives developers the choice of shooting themselves in the foot, although it's certainly possible to do it cleanly. As such, it is suited for developers who are comfortable with web development and have a clean style, but it is not for the developers who want Widgetized behavior a la winforms without having to delve too deeply into the markup.
I am always surprised at the lack of understanding of n-layer/tier design demonstrated by some of the loudest supporters of asp.net mvc. SOC has always been achievable in webforms. UI patters such as MVP have always been achievable in webforms. Its not the platforms fault that so many developers don't know how to design.
Back to the spaghetti question, I have to agree. The view is not 'dumb' as it should be if it contains conditional logic or tons of untestable code snippets.
Personaly, I much prefer the MVP pattern over the MVC one.
For the record :
I think the real problem with ASP MVC is the controller, it is trivial (in most language) to use (or to emulate) some template scheme (even in ASP classic) and any language can do model (with objects or not) but MVC forces you to separate the controller from the view and the model, bloating the code in the process.
A common websites relies on full-form-post/get and in AJAX, if you use both then you turn you "C" from MVC into a mess.
Ultimately, most programmer end "cheating", putting the ajax call in the VIEW layer.
In classic ASP, you didn't have a choice to move business logic out of the UI layer. In ASP.Net MVC, the "spaghetti" code is isolated the UI layer, the View; 90% of your logic will be in the "M" and "C" layers, which are regular, non-spaghetti C# classes.
The View is meant to be "dumb". Nothing critical in there from a business logic perspective. It's meant to be nearly disposable.
You can paint a room messily without doing any damage to the structure. If you decide to clean it up and re-paint, you don't need to call the architect. Same with the View.