Discussion :

[alex_vino]

Bonjour a tous,

Je voudrais connaitre laquelle des deux technologies, entre WebForms et MVC, vous me conseillez.
Je souhaite bien maitriser une des 2, mais je ne sais pas encore laquelle.

Comparaison des 2: Pré-requis techniques, documentation, communauté, puissance, maintenabilité, utilisation javascript/jQuery, applications mobiles, ainsi que pérennité car je ne souhaite pas apprendre quelque chose qui sera délaissé voire abandonné par Microsoft a la sortie de Windows 8 par exemple.

Merci de me faire partager votre expérience.


Vino.

[tomlev]

WebForms est pas encore mort, mais à mon avis ça va pas tarder vu le succès de MVC...

Avec WebForms, ça semble plus facile au début, mais finalement tu te retrouves assez vite avec du code spaghetti impossible à maintenir. Le modèle de développement semble similaire à celui de WinForms, et donc quand on vient de WinForms on a tendance à faire pareil en WebForms, ce qui est une grave erreur, car en fait ça n'a rien à voir... Pour un débutant en développement web, à mon avis WebForms est une très mauvaise chose, car il ne facilite pas la compréhension des problématiques inhérentes au web (distinction client/serveur, postback...)

Avec MVC, le modèle de développement est beaucoup plus propre, les vues ne contiennent que du HTML standard et un peu de code C# très simple, il n'y a plus de contrôles serveurs avec un ViewState lourdingue... Je ne fais pas beaucoup de développement web, mais pour moi c'est clair : la prochaine fois que je dois faire de l'ASP.NET, ce sera avec MVC.

Par rapport aux critères que tu as mentionnés :

• Pré-requis techniques : à mon avis MVC est plus simple, il y a moins de choses à comprendre (cycle de vie des pages, postback, viewstate etc)
• Documentation : les 2 sont bien documentés, comme tout le reste du .NET Framework
• Communauté : pour l'instant il y a sans doute plus de monde en WebForms parce que ça existe depuis plus longtemps, mais tu n'auras pas de mal à trouver de l'aide sur MVC, il y a de plus en plus de gens qui l'utilisent
• Puissance : ça veut pas dire grand chose... tout ce que tu peux faire en WebForms, tu peux aussi le faire en MVC, et inversement. MVC est à priori plus performant, vu qu'il est débarrassé de la lourdeur du ViewState
• Maintenabilité : avantage MVC, sans hésitation, vu la séparation très nette entre modèle, vue, et contrôleur
• Utilisation javascript/jQuery : avantage MVC là encore. C'est assez compliqué de faire du JS dans des pages WebForms, parce qu'on ne sait jamais très bien quel HTML va être généré par un contrôle serveur, et ASP.NET fait sa petite cuisine avec les identifiants, ce qui ne facilite pas les choses... Avec MVC, tu es plutôt encouragé à utiliser JS, jQuery est même inclus dans le template de projet standard.
• Applications mobiles : je sais pas trop comment ça marche, mais MVC inclus un mécanisme pour faire des vues différentes selon la plateforme du client (par exemple PC ou mobile)
• Pérennité : vu le succès de MVC, je ne pense pas que Microsoft l'abandonnera à court terme. WebForms n'est pas encore abandonné (il y a encore eu des nouveautés dans .NET 4), mais je pense qu'il ne faut pas s'attendre à ce que ça évolue encore beaucoup (ce n'est que mon avis, je n'ai pas d'infos là-dessus)

[Immobilis]

Salut,

"MVC" est une architecture, un modèle de développement. A ce titre il ne peut pas être abandonné.

"ASP.Net MVC" est la solution Microsoft pour l'implémenter. En regardant les statistiques des forums, on peut faire un raccourci rapide et dire que moins de monde postent dans le forum MVC. Bon, il est plus jeune aussi. Il faudrait connaître l'évolution des chiffres.

A mon avis:

• Je constate dans mon entourage que "ASP.Net MVC" n'est pas maîtrisé. Il est même plutôt inconnu. Moi-même je n'en ai jamais fait en production. Pourtant, j'ai bien l'impression de faire du "MVC";
• Pour avoir fait de l'ASP3, je trouve que "ASP.Net MVC" lui ressemble (mis à part Razor qui est un helper). L'exemple qui me choc le plus est qu'il faut aller chercher ses variables dans le request form! Le typage est perdu! Quelle regression!
• Voir du code C# (ou des balises serveur) dans la vue me hérisse le poil. Et finalement, je trouve que la séparation n'est pas si bien faite au contraire de WPF. Il y a autant de séparation entre une vue et son contrôleur qu'entre un webform et son code behind;
• Le lien entre la vue et son contrôleur se fait sur la base d'une nomenclature. Si tu ne la respecte pas le controleur ne trouvera pas sa vue...
• La dernière version du Framework te permet de donner tes propres identifiants à tes blocs html;
• L'"ASP.net" te permet aussi de faire du html pur;
• Le viewstate? Un viewstate cela se gère. Les applications de gestion (Intranet, Extranet) en tire énormement profit. Pour les autres, il suffit de le supprimer dans les contrôles qui n'en ont pas besoin.
• La maintenabilité est liée à l'architecture, au couplage, aux responsabilités de tes classes. Tu peux faire des spaghettis en MVC aussi.
• Pérennité? "ASP.Net MVC" est un modèle de projet dans Visual Studio. Il trouve son public, mais il n'est pas propre à l'environnement web. En effet, le modèle "MVC" existe depuis des années (1979 soit bien avant la création d'Internet). Ce que son inventeur en dit ne me semble pas lié à "ASP.Net MVC":

  The essential purpose of MVC is to bridge the gap between the human user's mental model and the digital model that exists in the computer. The ideal MVC solution supports the user illusion of seeing and manipulating the domain information directly. The structure is useful if the user needs to see the same model element simultaneously in different contexts and/or from different viewpoints.

  "MVC" restera, "WebForm" et "ASP.Net MVC" resisteront-ils à WPF et HTML5?
• Applications mobiles? Si "ASP.Net MVC" renvoit du HTML sous la maîtrise du développeur, je vois pas trop comment le code peut être adapté. Les applications mobiles sur les terminaux Microsoft utilisent Silverlight (WPF, xaml). Les sites internet pour mobiles ont un design qui doit être pensé. Si tu renvois un tableau dans ta page il restera un tableau quel que soit le terminal (PC ou mobile);
• Seul vrai avantage de "ASP.Net MVC": les tests unitaires.

Connaîs les deux et choisi en fonction de ton équipe, de l'usage.

A+

[tomlev]

L'exemple qui me choc le plus est qu'il faut aller chercher ses variables dans le request form! Le typage est perdu! Quelle regression!

Tu peux faire des vues fortement typées, en précisant le type du modèle. Tu as même l'auto-complétion
En tous cas je n'ai jamais vu une vue MVC qui va chercher des variables dans la requête... C'est le contrôleur qui prépare les données dont la vue a besoin, via le ViewModel. Si elles n'y sont pas, c'est que le contrôleur ne fait pas ce qu'il devrait...

Voir du code C# (ou des balises serveur) dans la vue me hérisse le poil.

Perso ça me gêne moins que des contrôles serveurs qui vont générer du HTML super lourd que tu ne contrôles pas du tout... Enfin bon, c'est une question de goût et d'habitude je suppose.

Tu as sûrement beaucoup plus d'expérience que moi en ASP.NET, mais as-tu vraiment essayé MVC ? Pour avoir fait un peu de WebForms et un peu de MVC, pour moi le choix est vite fait

[Jean-Michel Ormes]

Voici un billet de blog que j'ai trouvé assez complet qui pourra peut-être t'aider alex. Tu peux aussi t'inspirer du MVC Music Store si tu souhaites t'initier à ce langage.

[alex_vino]

Merci tomlev et Immobilis pour la qualité de vos posts comme toujours, c'est bien d'avoir différents points de vue.

Merci Jean-Michel pour le lien du blog, tres utile. J'avais téléchargé hier le Music Store sur CodePlex, super ta traduction.

Actuellement je fais du WebForms au boulot, et j'ai posé cette question parce que j'entend beaucoup de louanges d'ASP MVC.

Si je souhaite me perfectionner en WebForms ou apprendre MVC, c'est pour acquérir de nouvelles connaissances mais aussi parce que je veux réaliser mon site d'eCommerce d'ici la fin de l'année. Je serais seul sur le développement.
Je sais pas si cela dois influencer mon choix entre les deux.

[Immobilis]

générer du HTML super lourd que tu ne contrôles pas du tout...

Tu peux tout à fait contrôler le HTML. Voici un site que j'ai réalisé pour faire des tests: http://beta.videocrossing.fr/fr-FR/. Il y a quelques contrôles serveur sur lesquels je ne me suis pas attardé et pour lesquels j'ai laissé l'identifiant se générer tout seul. Si tu regardes le code source tu verras que le ViewState ne fait que quelques octets et que le code html est sous contrôle.

Enfin bon, c'est une question de goût et d'habitude je suppose.

De goût non, d'habitude oui.

mais as-tu vraiment essayé MVC ? Pour avoir fait un peu de WebForms et un peu de MVC, pour moi le choix est vite fait

J'ai essayé. C'est ce qui m'a permis de faire le constat dont je parle précédemment (nomenclature, request.form, tests unitaires). J'essaierai encore car "ASP.Net MVC" est intéressant. Pour l'instant, MVC ne m'apporte pas suffisamment d'innovations.

NB: Mis à part que le code behind est difficilement testable, tous les points cités dans le billet sont aussi faisables en ASP.Net:

• Contrôle total sur le code HTML généré
• Vues légères sans code behind
• Moteurs de rendu pluggables (Services Web, médias mobiles, ….)
• Architecture RESTful
• Pas de postback ni de ViewState

[tomlev]

Tu peux tout à fait contrôler le HTML

Certes, mais pas de façon aussi simple qu'avec ASP.NET MVC. Si j'ai bonne mémoire, il faut hériter du contrôle et overrider sa méthode Render, pas super pratique... (à moins qu'il y ait une façon plus simple que je ne connais pas)

De goût non

Ah bon ? Toi tu préfères avoir des contrôles serveur, moi je préfère avoir du code intégré dans la vue. C'est donc clairement une question de préférence, et donc de goût... De tout ce que j'ai pu écrire, je ne pensais pas que cette phrase-là prêterait à controverse

J'ai essayé. C'est ce qui m'a permis de faire le constat dont je parle précédemment (nomenclature, request.form, tests unitaires). J'essaierai encore car "ASP.Net MVC" est intéressant. Pour l'instant, MVC ne m'apporte pas suffisamment d'innovations.

OK ! J'avais l'impression d'après tes propos que tu en parlais sans vraiment connaître, au temps pour moi