ASP.NET MVC reminds me of old Classic ASP spaghett

Question

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 spaghetti code with all the jumping in and out of HTML and ASP.NET with yellow delimiters everywhere making it impossible to read? What ever happened to the importance of code/design separation?? I was really sold on the new technology until the tutorials hit the View page development section.

Or am I missing something? (And don't say you can use the template to help because it's jsut moving the spaghetti to another location - sweeps it under the rug - it doesn't fix the problem)

Answer 1

Finlay Microsoft is correcting his error with ASP-Classic to ASP.NET step. 70% of old asp programmers went to PHP because ASP.NET was to complex.

They tough that everything can be solved with ASP.NET drug and drop menus. And in the end everything is inside form tag! We are building big "web form" not web sites. Just look at the HTML from any ASP.NET site. Absolutely horrible!

ASP.NET MVC is the new HOPE for cleaner more organised HTML code and powerful business logic.

Answer 2

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.

Answer 3

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.

Answer 4

If you don't like the default View engine, you can use another one.

As per Scott Guthrie's blog:

One of the things the team has done with ASP.NET MVC is to make sure you can use any type of "view engine" you want with it. This provides a lot of flexibility to customize the rendering engine however you want.

We are going to be investigating some more declartive view engines in the future - although nothing specifically planned just yet.

Examples of alternative View engines are NHaml discussed here, Spark discussed here and NVelocity discussed here.

Answer 5

It is about seperation of concerns. In Classic ASP, it was a mix of business logic and presentation logic, with nasty includes thrown in for libraries.

The syntax is similar at this point, but the purpose is not. In the view, you should only be doing presentation logic. You still can put business logic in there, nothing stops you (unfortunately). It depends on the developer, which is still my biggest concern.

Answer 6

Check out the StringTemplate view engine, it looks nice and clean.