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

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.

Answer 2

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

Answer 3

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.

Answer 4

I think the problem with the ASP.NET view engine is that there are no restrictions on what you can do, since its just a .NET language embedded in XHTML.

In contrast, take a look at the Django template engine. In the Django framework, the controllers and models are written using the full-blown Python language, but the view template engine defines a restricted language which only provides basic programming constructs (conditional, loops, etc). This restricted language resembles Python but it isn't actually Python, so it cannot invoke arbitrary code like external libraries. It can only access the model data that is passed in to the view.

Any view engine that embeds a general purpose language is going to have the problem where people abuse it and do things they shouldn't in the view. So with those engines you really need to have the due diligence to constrain yourself from doing things other than access the model data.

Answer 5

After programming MVC for a while now, I'm going back to ASP.NET.

MVC is indeed a nice step forward from classic ASP or PHP, but it is a big step back compared to ASP.NET.

Many things that can be programmed with a few steps in ASP.NET need a lot more work in MVC. Making it harder to meet deadlines.

The technology has it's merits, but isn't mature yet.

Maybe in version 3.0 ...

Answer 6

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.