Comparaison entre ASP.NET Web Forms et ASP.NET MVC

J'ai fait pas mal de développements ASP.NET Web Forms au cours de ma carrière, et je me suis récemment décidé à tester ASP.NET MVC. Après avoir joué avec le produit, j'avais un a priori assez négatif (j'expliquerai pourquoi un peu plus loin). Histoire d'avoir d'autres points de vue, je me suis rendu à la rencontre alt.net du 12/03/2009, dont le sujet était précisément ASP.NET MVC (au passage, j'en profite pour saluer tous les Winwisiens qui étaient présents, ainsi que Clément). Et j'ai mis un peu d'eau dans mon vin... Histoire de pouvoir comparer les deux technologies, je vous propose de les confronter sur plusieurs points.

Gestion de l'état

ASP.NET Web Forms propose les notions de Postback et de ViewState pour permettre aux contrôles présents sur une page de conserver leur état suite à des aller-retour successifs vers le serveur. Ce mécanisme fonctionne bien, à condition de ne pas en abuser (avoir un ViewState de plusieurs centaines de Ko...) et d'avoir une bonne connaissance du cycle de vie de la page ASP.NET. Avec ASP.NET MVC, vous pouvez oublier Postback et ViewState... Pourquoi pas, après tout le protocole HTTP est bien censé être sans état. Et de nombreux sites fonctionnant très bien sont écrits en PHP ou avec Ruby on Rails Smile Puisque vous ne pouvez plus conserver l'état de vos contrôles, vous devrez recourir à AJAX pour ne mettre à jour que le strict nécessaire sur vos pages. ASP.NET AJAX et jQuery pourront vous aider sur ce point (au passage, si vous créez dans Visual Studio un site ASP.NET MVC, les librairies jQuery sont fournies de base).
Pour résumer, utiliser ASP.NET MVC implique encore plus qu'avec ASP.NET Web Forms que vos équipes de développement aient une bonne connaissance des langages Javascript et CSS. Attention, je ne dis pas qu'avec ASP.NET Web Forms il est possible de se passer de connaître Javascript ou les CSS, bien au contraire Big Smile Mais vu qu'avec ASP.NET MVC vos applications devront être plus "ajaxifiées", il vous faudra bien maîtriser la programmation côté client.

Testabilité

Lorsque Microsoft a publié il y a quelques années de cela ASP.NET Web Forms, son discours était plus ou le moins le suivant : "notre produit est conforme aux principes dictés par MVC, car les *.aspx sont les vues et les *.aspx.cs les contrôleurs". En pratique les *.aspx.cs mélangent souvent vue et contrôleur, donc tester une telle couche web sera très difficile. En revanche, ASP.NET vous permettra de facilement tester vos contrôleurs, car ils sont faiblement couplés avec vos vues.
Après voir dit tout cela, je vais le relativiser Smile D'abord, tester la couche web d'une application Web Forms est tout à fait possible, à condition qu'elle soit bien architecturée, par exemple via l'utilisation du design pattern MVP (qui dérive de MVC). Ensuite, dans le cadre d'une application ASP.NET MVC, veillez à ne pas multiplier inutilement les contrôleurs et surtout interdiction d'y effectuer le moindre traitement d'affichage. Ce genre de tâche doit être réservé aux vues.
Enfin bref dans les deux cas essayez d'avoir sous la main un bon architecte Wink

Performances
Le principe d'ASP.NET Web Forms est le suivant : lorsqu'une page est demandée, plusieurs événements sont déclenchés par le framework de Microsoft et un arbre des contrôles est construit; le flux à renvoyer au client est généré à partir de cet arbre. La logique qui prévaut avec ASP.NET MVC est totalement différente : l'URL demandée est décortiquée de manière à déterminer quel contrôleur sera invoqué, ce dernier décidant quelle vue devra être utilisée. Je n'ai pas fait de test, mais ma science de la pifométrie tend à me faire penser qu'ASP.NET MVC est plus performant car :
  • Aucun arbre des contrôles à construire.
  • Le ViewState n'existe pas : cela fait moins de traitements côté serveur et des réponses plus légères.
  • Il n'y a pas les événements PreRender, Render, ... donc encore une fois cela implique moins de travail sur le serveur.
Codage
Avec ASP.NET MVC, vous pouvez utiliser des fichiers code-behind pour vos vues, mais cela est déconseillé, car ce n'est pas dans l'esprit MVC : ce sont vos contrôleurs qui doivent faire tous les traitements, et transmettre des données aux vues qui sont censées ne posséder aucune intelligence. Du coup, vous serez confronté au problème dit de la "soupe de tags", illustré par Jeff Atwood dans un excellent billet. Un exemple (en Ruby on Rails, mais le principe est excatement le même avec ASP.NET MVC) valant mieux qu'un long discours, voici à quoi peut ressembler une soupe de tags :

Tag soup


Pas très appétissante, la soupe... Même si le code ci-dessus est largement perfectible.
Autre point faible d'ASP.NET MVC : il n'existe pas vraiment d'équivalent aux contrôles serveur (en revanche, les contrôles utilisateur sont disponibles en tant que ViewUserControl). En fait si, vous pouvez bien utiliser des contrôles tels que le Repeater (pour être précis, tous les contrôles ne nécessitant pas une balise form avec runat="server"), mais vous devrez associer un code behind à vos vues, ce qui, je vous le rappelle, est déconseillé... Donc pour restituer des tableaux dans vos pages, vous aurez à mixer du code C# (boucle foreach) et des balises HTML. Voici un exemple que j'ai repompé à cette adresse : http://www.asp.net/learn/mvc/tutorial-11-cs.aspx

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
<%@ Page Language="C#" MasterPageFile="~/Views/Shared/Site.Master" AutoEventWireup="true" CodeBehind="Index.aspx.cs" Inherits="MvcApplication1.Views.Home.Index" %>
<%@ Import Namespace="MvcApplication1.Models" %>
<asp:Content ID="indexContent" ContentPlaceHolderID="MainContent" runat="server">

<table>
<tr>
<th>Id<th>Title<th>Release Date</th>
</tr>
<% foreach (Movie m in (IEnumerable)ViewData.Model)
{ %>

<tr>
<td><%= m.Id %></td>
<td><%= Html.Encode(m.Title) %></td>
<td><%= m.DateReleased %></td>
</tr>
<% } %>
</table>

</asp:Content>

Pour en finir sur la partie codage, je reproche à ASP.NET MVC de ne pas tojours promouvoir une approche suffisamment orientée objet : vous utiliserez souvent des méthodes statiques de la classe HtmlHelper (par exemple BeginForm()), ou écrirez des méthodes d'extension pour pouvoir simuler ce qu'il est possible de faire avec les contrôles serveur. Par exemple, regardez ici une manière de simuler le contrôle Repeater...

Conclusion
Que choisir pour vos nouvelles applications ? ASP.NET Web Forms ou ASP.NET MVC ? Cela dépend de beaucoup de paramètres, chacune des solutions permettant d'obtenir d'excellents résultats. Prenez en considération tous les points ci-dessus, ainsi que les éléments suivants :
  • Si vous devez intégrer dans vos équipes des développeurs issus des mondes PHP, Ruby on Rails, ... ASP.NET MVC sera incontestablement la meilleure solution. Pourquoi ? Tout simplement parce qu'ils connaîtront les concepts MVC ! Ils n'auront "qu'à" apprendre C# 3.0 et certaines classes du Framework .NET pour commencer à être productifs.
  • Avec ASP.NET MVC, vous avez un contrôle total sur le code (X)HTML généré, au prix de plus d'efforts sur les parties Javascript, CSS et bien sûr HTML. Cela permet de coder plus facilement des pages XHTML qui passent au validateur du W3C. C'est moins évident avec ASP.NET Web Forms (vous aurez à traiter les événements PreRender et Render), mais en compensation vous disposez de plusieurs contrôles serveurs éprouvés, et vous pouvez assez facilement créer les vôtres.
J'espère que cet article pourra vous être utile. N'hésitez pas à poster des commentaires pour me donner votre point de vue Big Smile

Libérer de l'espace disque sur une machine de dev ou un serveur Team Build

Vous avez une machine de développement sur laquelle vous codez des sites ASP.NET ? Ou alors un serveur Team Build ? Vous manquez régulièrement d'espace disque sur votre partition C:\ ? Alors ce billet pourra vous intéresser. Lorsqu'un site ASP.NET est compilé, des fichiers sont générés dans le dossier <windir>\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files. Ce répertoire a une fâcheuse tendance à enfler indéfiniment... Heureusement, grâce à PowerShell, la solution à ce problème est simple. A l'aide de votre éditeur de texte préféré, créez un fichier que vous appellerez par exemple "DeleteTemporaryFiles.ps1" et saisissez le code suivant :

1
Get-ChildItem -recurse "C:\Windows\Microsoft.NET\Framework\v2.0.50727\Temporary ASP.NET Files"
| Remove-Item -recurse -force


Ensuite, utilisez la planificateur de tâches de Windows de manière à exécuter ce script une fois par jour.

1
powershell -command "& 'D:\Scripts\DeleteTemporaryFiles.ps1'"

Pour que cela fonctionne, il faut bien sûr que le compte utilisé pour lancer le script ait un minimum de droits...

Encore un nouveau sur CodeS-Sources

Bonjour à tous !

Je suis nouveau sur Codes-Sources, alors je me présente : Farid LAOUFI, ingénieur consultant chez Winwise, à votre service Big Smile

Sur je blog j'écrirai des billets autour de C#, du framework .NET, d'ASP.NET et de Team System. Je vous parlerai également d'architecture logicielle.

A bientôt !


Les 10 derniers blogs postés

- Merci par Blog de Jérémy Jeanson le 10-01-2019, 20:47

- Office 365: Script PowerShell pour auditer l’usage des Office Groups de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 11:02

- Office 365: Script PowerShell pour auditer l’usage de Microsoft Teams de votre tenant par Blog Technique de Romelard Fabrice le 04-26-2019, 10:39

- Office 365: Script PowerShell pour auditer l’usage de OneDrive for Business de votre tenant par Blog Technique de Romelard Fabrice le 04-25-2019, 15:13

- Office 365: Script PowerShell pour auditer l’usage de SharePoint Online de votre tenant par Blog Technique de Romelard Fabrice le 02-27-2019, 13:39

- Office 365: Script PowerShell pour auditer l’usage d’Exchange Online de votre tenant par Blog Technique de Romelard Fabrice le 02-25-2019, 15:07

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Stream Portal par Blog Technique de Romelard Fabrice le 02-21-2019, 17:56

- Office 365: Script PowerShell pour auditer le contenu de son Office 365 Video Portal par Blog Technique de Romelard Fabrice le 02-18-2019, 18:56

- Office 365: Script PowerShell pour extraire les Audit Log basés sur des filtres fournis par Blog Technique de Romelard Fabrice le 01-28-2019, 16:13

- SharePoint Online: Script PowerShell pour désactiver l’Option IRM des sites SPO non autorisés par Blog Technique de Romelard Fabrice le 12-14-2018, 13:01