How does ASP.Net MVC differ from Classic ASP (not ASP.Net--the original ASP)

I'm trying to get a high-level understa开发者_JS百科nding of ASP.Net MVC, and it has started to occur to me that it looks a lot like the original ASP script. Back in the day, we were organizing our "model"/business logic code into VBScript classes, or into VB COM components.

Of course, now we have the additional power of c# and the .net framework classes. Besides the high-level oo and other capabilities in c# and .Net, what are the other major differences between the original ASP and ASP.Net MVC?

There are three main differences: URL mapping, separation of logic from presentation, and strong typing.

URL Mapping

With classic ASP there is a smooth transition from writing HTML pages to writing HTML pages with dynamic content. As with static HTML files, each URL has a direct mapping to a file in the filesystem. The same thing is more or less true of ASP.NET, for what it's worth.

In ASP.NET MVC, each "family" of URLs maps to a Controller object (stored in the /Controllers directory, by default), where each member of the family calls a method when accessed. At the end of each method (typically), you tell it to render a particular view (stored in a folder named after the controller in the /Views directory), which is a lot like a classic ASP page with all of the logic separated out.

This gives you logical and SEO-friendly URLs and groups related functionality together.

Separation of Logic from Presentation

In classic ASP it's common to find pages where a bit of HTML is included at the top, and then a database connection is opened and some things are read from the database while being output to the user, and then some more html, and then another database statement, and so on.

In ASP.NET MVC, your business logic (e.g. validation) goes in the model layer (you can choose from one of several dozen, but popular choices are LINQ-to-SQL and LINQ-to-Entity-Framework), your human interface logic goes in the controller (e.g. populating a State/Province menu based on the Country selection), and your presentation (the actual HTML you can hand to a designer to edit) goes in the view.

Aside from keeping things organized, this helps a great deal with being able to write automated tests for things. You can send a mocked-up object to your view and make sure it looks good, you can send bad data to your model and make sure it complains, and you can make sure that the object your controller sends out to your view is consistent with what it reads from the model.

Strong Typing and Compilation

ASP.NET is strongly typed and compiled. This is a double-edged sword. On the one hand, it will catch a lot of stupid programmer mistakes at compile time. On the other hand it, that means you're left with "infinity minus one" possible errors in your code (unit testing can make it infinity minus some larger number). Also, you'll have to do things like:

if (MyArray.Length > 0)

rather than

if (MyArray.Length)

But IMHO that's a small price to pay for the speed and sanity-checking you get from strong typing.

The bigger downside to compiled languages in a big framework is that deployment becomes much more of a production than it is with something like Classic ASP. You can't just copy a couple of files to the web server to update your app. You typically have to take the webserver down (hopefully you have a redundant pair) and recompile, which can take minutes.

ASP.NET MVC has a lot of plumbing infrastructure: for example, the routing engine which automatically invokes the right controller and action and can extract bits from the URL to pass as action arguments; or the convention-based location of views. It also provides more structure for passing data from the controller into the view (the ViewData object).

Also, crucially, MVC supports view engines. You can write raw HTML with helpers in it, but you can also use view engines like Web Forms, Spark, NHaml, etc. which allow you to write more concise view code, create reusable components (e.g. Web Forms controls), etc. This wasn't possible in ASP Classic.

Classic ASP used VBScript, which does not have classes. It's not object-oriented at all.

Very often with different technologies we can achieve the same final result. To create simple sites is almost irrelevant to the choice of technology. But when you want to make a large complex site the presence or absence of a framework that allows to optimize the code, keep well organized and efficiently divide may play a role crucial and greatly reduce the work.

ASP Classic does not achieve the same results reached by asp net mvc.

If we omit the obvious differences between c # vb script I would say that the difference main is that you can keep your code better organized.

As with classic ASP is very easy to make "spaghetti code and, with asp mvc, on the contrary, it is very easy to keep everything tidy and separate the code business logic from display.

Not only that.

Asp Net Mvc seamlessly integrates with technologies such as that EntityFramework allow a further breakdown and organization of the code.