ASP.NET MVC reminds me of old Classic ASP spaghett

问题:

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)

回答1:

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.

回答2:

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.

回答3:

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.

回答4:

MVC vs. generic ASP.NET like the difference between automatic and manual transmissions. Use a manual if you want to determine which gear to use for which purposes, when to shift, and optimize for efficiency. Use the automatic if you want something that just works but may not be very well optimized, or flexible, or easy to debug (which you won't need to do as often.)

Classic ASP was a manual transmission with only second gear.

回答5:

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.

回答6:

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.

回答7:

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 ...

回答8:

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

回答9:

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.

回答10:

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

回答11:

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.

回答12:

Because the people behind MVC really liked ASP/JSP pages and want to implement it all over again. They appear to hate:

• ViewState
• Existing ASP.Net Controls
• Clean Html
• Existing User Controls
• Postbacks

They appear to love:

• Re-inventing the wheel
• REST-ful urls

MVC essentially is a way of forcing a separation of code from presentation. If a developer actually cared enough, this could be easily acheived with normal Asp.Net. It is possible to punk the whole "separation" system anyway, so I don't really see the point.

That being said, there is some merit to it.. but not enough to outweigh the problems. MVC version 3 I'm sure will be awesome.

And before anyone marks me down -1, see how many MVC questions I've answered. I know what i'm talking about.

UPDATE If you are taking your separation seriously, upon looking at it, chaiguy1337 is onto a good thing. String Template looks great because it does not allow any code in your front end! In my opinion, the ASP.net MVC team dropped the ball on MVC.

回答13:

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.

回答14:

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.