So your company wants to create their next product delivered to the browsers, and you have all these young programmers telling: “we should do it in ASP.NET”, wait, no, “we should do it in MVC”?
What does that even mean, aren’t both .NET technologies for the web, published by the same Microsoft?
Shouldn’t we just.. use the newest wherever possible?
Well, these two ASP.NET technologies are complementary, and to make the best match on their fitness, I will try to wrap up their core philosophies.
ASP.NET Web Forms is indeed what the original .NET framework shipped with, and most people rightfully call it just ASP.NET.
It is Microsoft’s attempt at UI componentry for the web: that is, it’s made of controls, as opposed to the classic ASP, and it tries to mimic the Windows Forms development, with advantages and disadvantages that I will try to outline here:
>> Why would you use Web Forms?
You can design your application just like an event-driven and stateful desktop one, and you can do it fast – using the existing controls or integrating third party ones.
This makes ASP.NET Web Forms very well suited for e.g. porting existing desktop applications.
La perte de contrôle sur l’affichage du code HTML a pour conséquence un support médiocre des standards à venir (par exemple, des balises dégradées en HTML 5 seraient toujours affichées par les contrôles existants), et l’existence de contrôles dans les pages peut rebuter certains concepteurs de sites web.
L’abstraction dynamique impliquant une baisse de performance (des volumes importants Viewstate transférés entre le client et le serveur à chaque clic), ces applications conviennent mieux aux développements Intranet. Si vous ne le souhaitez pas, il vous faudra travailler activement autour de Viewstate.
L’abstraction « événementielle » induit qu’il y a peu de chance de trouver, sur votre page web, des éléments à mettre en favoris (des éléments possédant leur propre URL), et si c’est le cas, l’URL peut ne pas fonctionner plus tard en cas de perte de son état dynamique.
>> Et ASP.NET MVC ?
The loss of control over the HTML code output means weak support for future standards/browsers (e.g. tags deprecated in HTML5 would still be output by existing controls) and the presence of controls in the pages may put off some web designers.
The “stateful” abstraction costs you a performance hit (large Viewstate passed between client and server at each click), which make the application more suited for Intra-net deployment. You have to actively work around the Viewstate if you don’t want it.
The “event-driven” abstraction means that rarely are there any elements on your web page that can be bookmarked (that have their own URL) and when they are, the URL might not work later because of the state being lost.
Now let’s have a look at ASP.NET MVC. This is not the first MVC framework for ASP.NET , proving that in fact ASP.NET is a very extensible platform – but this is the one backed by Microsoft, with Visual Studio support and all.
Model-View-Controller is the name of a software pattern used in GUI development, which happens to map very nicely to HTTP’s stateless request/response model.
Why would you use MVC?
First, there’s the URLs: the site can be started by designing SEO-friendly URLs, which have no extension and are not at all linked with how your files are stored on the server. These may all be used as bookmarks, unless you actively prevent that.
Then, the Views – which are much more designer-friendly, because they have no references to controls in them (no hidden markup).
So MVC seems like the perfect choice for Internet sites, which don’t require large forms to be filled and then checked against business rules or datasets to be explored, sorted and filtered.
Know both, use the one that fits.