Quand privilégier les formulaires Web ASP.NET par rapport à MVC
Je sais que Microsoft a dit
ASP.NET MVC ne remplace pas WebForms.
Et certains développeurs disent que WebForms est plus rapide à développer que MVC. Mais je crois que la vitesse de codage se résume au niveau de confort avec la technologie, donc je ne veux pas de réponses dans ce sens.
Étant donné qu'ASP.NET MVC donne au développeur plus de contrôle sur leur application, pourquoi les formulaires Web ne sont-ils pas considérés comme obsolètes? Sinon, quand devrais-je privilégier les WebForms plutôt que MVC pour les nouveaux développements?
Les formulaires Web vs MVC semblent être un sujet brûlant en ce moment. Tout le monde que je connais vante MVC d'être la prochaine grande chose. D'après mes petites touches, cela semble correct, mais non, je ne pense pas que ce sera la fin des formulaires Web.
Mon raisonnement, et le raisonnement sur la raison pour laquelle les formulaires Web seraient choisis plutôt que MVC, a plus à voir avec une perspective commerciale plutôt que ce qui est meilleur que l'autre.
Le temps/l'argent sont les principales raisons pour lesquelles les formulaires Web seraient choisis plutôt que MVC.
Si la plupart de votre équipe connaît les formulaires Web et que vous n'avez pas le temps de les mettre à jour sur MVC, le code qui sera produit peut ne pas être de qualité. Apprendre les bases de MVC puis sauter et faire cette page complexe que vous devez faire sont des choses très différentes. La courbe d'apprentissage est élevée, vous devez donc en tenir compte dans votre budget.
Si vous avez un grand site Web écrit entièrement dans des formulaires Web, vous pourriez être plus enclin à créer de nouvelles pages dans des formulaires Web afin de ne pas avoir deux types de pages très différents dans votre site.
Je ne dis pas que c'est une approche tout ou rien ici, mais cela rend votre code plus difficile à maintenir s'il y a une séparation des deux, surtout si tout le monde dans l'équipe n'est pas familier avec MVC.
Mon entreprise a récemment fait trois pages de test avec MVC. Nous nous sommes assis et les avons conçus. Un problème que nous avons rencontré est que la plupart de nos écrans ont la fonctionnalité Afficher et modifier sur la même page. Nous avons fini par avoir besoin de plusieurs formulaires sur la page. Pas de biggy, sauf que nous n'utiliserions pas notre page principale. Nous avons dû le réorganiser pour que les pages de formulaires Web et les pages MVC puissent utiliser la même page maître pour une apparence et une convivialité communes. Nous avons maintenant une couche supplémentaire d'imbrication.
Nous devions créer une toute nouvelle structure de dossiers pour ces pages afin qu'elle suive la séparation MVC appropriée.
Je sentais qu'il y avait trop de fichiers pour 3 pages, mais c'est mon opinion personnelle.
À mon avis, vous choisiriez des formulaires Web plutôt que MVC si vous n'avez pas le temps/l'argent à investir dans la mise à jour de votre site pour utiliser MVC. Si vous optez pour une approche à demi-ars, ce ne sera pas mieux que les formulaires Web que vous avez maintenant. Pire, vous pourriez même mettre cette technologie en échec dans votre entreprise si elle est gâchée, car la haute direction pourrait la voir comme quelque chose de inférieur à ce qu'elle sait.
J'ai développé des applications ASP .Net WebForms pendant 3 ans, et après une journée de tutoriel MVC, j'ai été vendu. MVC est presque TOUJOURS la meilleure solution. Pourquoi?
- Le cycle de vie des pages est plus simple et plus efficace
- Il n'y a pas de contrôles en dehors des contrôles html. Vous n'avez pas besoin de déboguer votre sortie pour voir ce que ASP .Net génère.
- Les ViewModels vous donnent un pouvoir immense et évitent d'avoir à effectuer une liaison de contrôle manuelle et éliminent de nombreuses erreurs liées à la liaison.
- Vous pouvez avoir plusieurs formulaires sur une page. C'était une sérieuse limitation de WebForms.
- Le Web est sans état et MVC correspond mieux à l'architecture du Web. Webforms présente l'état et les bogues que vous avez avec lui en introduisant ViewState. Le ViewState est automatique et fonctionne en arrière-plan, il ne se comporte donc pas toujours comme vous le souhaitez.
- Les applications Web doivent fonctionner avec ajax ces jours-ci. Il n'est plus acceptable de charger des pages complètes. MVC rend ajax tellement meilleur, plus facile et plus efficace avec JQuery.
- Parce que vous pouvez avoir plusieurs formulaires sur une page et que l'architecture est pilotée par des appels à des URL, vous pouvez faire des choses amusantes comme ajax charger un formulaire différent, comme un formulaire de modification dans votre page actuelle à l'aide de JQuery. Une fois que vous vous rendez compte de ce que cela vous permet de faire, vous pouvez facilement faire des choses incroyables.
- ASP .Net WebForms n'est pas seulement une abstraction sur html, il est extrêmement complexe. Parfois, vous obteniez un bug étrange et luttiez avec lui beaucoup plus longtemps que nécessaire. Dans de nombreux cas, vous pouviez réellement voir ce qu'il faisait mal, mais vous ne pouviez rien y faire. Vous finissez par faire des solutions de contournement étranges.
- WebForms ne fait pas une bonne technologie pour les concepteurs. Les concepteurs aiment souvent travailler directement avec du HTML. Dans MVC, c'est une vue, dans WebForms, c'est une demi-journée de travail.
- Comme la plate-forme Web évolue rapidement, les formulaires Web ne suivent pas. Il n'est pas au courant des nouvelles balises ou fonctionnalités de HTML5, il restituera toujours les mêmes choses, sauf si vous obtenez (souvent) des contrôles tiers coûteux ou attendez que Microsoft émette une mise à jour.
- Les contrôles dans WebForms vous limitent de bien des façons. Dans MVC, vous pouvez simplement récupérer une bibliothèque JQuery et l'intégrer dans vos modèles.
Je sais que certains des problèmes ci-dessus ont été résolus dans une certaine mesure à mesure que WebForms évolue, mais c'était mon expérience d'origine. Dans l'ensemble, je trouverais extrêmement difficile de trouver une analyse de rentabilisation pour WebForms à moins qu'un projet ne l'utilise déjà.
J'ai envoyé un e-mail Scott Guthrie , un expert MVC chez Microsoft. Et probablement l'homme le plus qualifié pour répondre à cette question. Il a eu la gentillesse de répondre:
"Différents clients recherchent des approches de programmation différentes, et beaucoup aiment WebForms et pensent que c'est génial. D'autres aiment MVC et pensent que c'est génial. C'est pourquoi nous investissons dans les deux."
Donc, pour moi, cela dit que ce n'est pas un problème technique. C'est plus une "question douce", si vous voulez. Une préférence personnelle. C'est ce que plusieurs d'entre vous ont dit.
Merci pour toutes les réponses.
C'est une question obsolète avec beaucoup de réponses, mais aucune n'avait la réponse que je m'attendais à voir figurer.
La réponse courte est:
- Utilisez ASP.NET MVC si vous avez l'intention de créer correctement une application Web avec des conventions de programmation modernes et des modèles adoptés par l'industrie pour la plate-forme ASP.NET. En revanche, vous serez censé savoir comment fonctionnent les ressources HTML et côté client (Javascript, CSS) ainsi que la montée en puissance de la mentalité de programmation MVC qui a une courbe d'apprentissage abrupte mais atteint une fin soudaine une fois saisie.
- Utilisez les formulaires Web ASP.NET si vous utilisez ou souhaitez utiliser un GUI - centric, RAD (Rapid Application Development) , approche par glisser-déposer pour prototyper quelque chose très rapidement, c.-à-d. comportement du bouton-poussoir/grille de données câblé en 15 minutes, et la solution n'est pas destinée à être prise en charge par les développeurs. Ou, Utilisez les formulaires Web ASP.NET si vous avez une expérience en GUI ou développement Windows Forms et que vous souhaitez transférer vos connaissances sur le Web.
Mais pour bien regarder cela, vous devez comprendre l'histoire de chacun.
ASP.NET Web Forms était la réponse de Microsoft à ceux qui avaient créé des applications Web dynamiques à l'aide des contrôles ActiveX Visual Basic 6, des DLL VB6 sur le serveur et ASP Classic. À l'époque, le développement Web utilisant ces outils Microsoft étaient un vrai gâchis. Avec l'ensemble du .NET Framework qui était la sortie de Microsoft pour revenir essentiellement à la planche à dessin sur la façon de faire une programmation commerciale productive sur la pile Windows, ASP.NET Web Forms était, en sa journée, incroyable et magnifique.
L'approche globale était de donner aux développeurs le meilleur des deux mondes de quelque chose de très similaire au développement d'applications Windows, mais avec la puissance des services Internet. L'idée était que, tout comme avec un "formulaire" VB6/WinForms (une fenêtre) de même une page Web est un formulaire (tout comme une fenêtre, voir) , et sur ce formulaire, vous pouviez glisser-déposer des étiquettes, des zones de texte, des grilles de données, des boutons et d'autres choses auxquelles les développeurs de l'interface graphique VB/WinForms étaient habitués.
Pour faire faire quelque chose à un bouton, après l'avoir glissé-déposé, il vous suffit de double-cliquer dessus dans le concepteur et vous êtes dans l'éditeur de code, indiquant au formulaire ce qu'il doit faire lorsque cet événement "clic" se produit. C'est exactement ainsi que les développeurs de l'interface graphique Windows ont créé des logiciels en utilisant GUI l'outillage de VB6 et des outils concurrents, sauf que maintenant le code s'exécute sur le serveur! Hou la la!
C'était la technologie de 2002. Incroyable et beau en son temps comme réponse à Internet GUI solutions pour RAD développement, cela a apporté un sentiment de puissance à un monde désordonné de développeurs de logiciels qui avaient des objectifs commerciaux qu'ils devaient atteindre.
Malheureusement, ce modèle de programmation met tellement l'accent sur la métaphore de la programmation de l'interface graphique Windows qu'il emporte avec lui le fardeau de ses détails de mise en œuvre nécessaires, tous les bagages encombrants nécessaires pour s'adapter aux cycles de vie des événements et le rangement des moches détails du HTML simple et script que ces composants et contrôles de glisser-déposer produiraient. Et à la fin de la journée, les développeurs prenant en charge de vraies applications devaient inévitablement creuser profondément dans ces composants ou écrire les leurs, et par conséquent, ils mèneraient des batailles avec cette infrastructure, des batailles qui laisseraient des tas de piles de cruches, de cheveux tirés et larmes.
Sauvegarder. Lavez-vous les mains. Examinons à nouveau le problème commercial. Quels sont nos objectifs commerciaux?
Nous devons construire et gérer les applications web. Nos contraintes sont que nous avons le World Wide Web, qui se trouve sur HTTP, HTML, Javascript et CSS, et sur le serveur, nous avons des règles métier, des bases de données et une petite poignée de grands langages de programmation (par exemple C #). Avons-nous vraiment besoin de cette métaphore de l'interface graphique Windows pour piloter notre méthodologie de développement? Pourquoi ne pouvons-nous pas nous concentrer uniquement sur les problèmes d'application et supprimer les métaphores de l'interface graphique?
C'est là qu'ASP.NET MVC entre en jeu. Cela a commencé par une rébellion de développeurs qui se faisaient appeler "Alt.Net" et qui voulaient revenir à des principes de développement logiciel appropriés et purs. Plus de bruit, concentrez-vous uniquement sur les objectifs commerciaux et les meilleures pratiques logicielles.
Dans ce cas, cela se traduit vraiment par:
- Séparation des préoccupations . Par exemple, un composant de données n'a pas besoin de savoir comment ses données seront rendues, et le balisage de vue ne doit pas être encombré de détails de configuration de connexion à la base de données, et de cette manière, un développeur peut se concentrer sur son domaine de préoccupation lors de la modification et tester le code.
- Exposition et prise en charge complète de l'exposition aux détails du HTML et des ressources connexes . Dans les formulaires Web, le HTML est caché, les développeurs sont découragés de s'occuper de cela. Dans ASP.NET MVC, les développeurs sont plutôt encouragés pour gérer ces détails; en fait, c'est une nécessité. L'avantage ici est que le développeur peut réapprendre à apprécier la sémantique propre de HTML, CSS et script, et travailler avec plutôt que contre.
- Testabilité des objets métier . Les contrôleurs et les modèles sont bien mieux adaptés aux tests unitaires programmatiques, de sorte que les implémentations peuvent être validées pour répondre aux objectifs de l'entreprise et que les modifications peuvent être vérifiées afin qu'elles ne se cassent pas. Avec les formulaires Web, il était difficile de tester, car les composants n'étaient pas conçus pour être testés individuellement et l'ensemble de la sortie de développement tournait autour de formulaires de page et de leurs cycles de vie d'événement avec la boue de la logique métier et de la logique de présentation profondément entrelacées .
Notez que HTML est déjà un langage de balisage de très haut niveau, tout comme Javascript un langage de programmation de haut niveau. L'histoire aurait été différente si nous avions traité du langage de l'Assemblée et du C.
S'étendant sur # 2, un autre objectif d'ASP.NET MVC est de permettre aux développeurs d'organiser les détails frontaux de la partie `` vue '' de leurs solutions et de tirer parti de la richesse des fondations sur lesquelles le reste de l'industrie s'est appuyée. la plateforme client front-end.
Vous constaterez que les développeurs ASP.NET MVC se sentent chez eux en utilisant des bibliothèques Javascript riches et des techniques de modélisation côté client sans se battre avec l'architecture côté serveur. Ce n'était pas le cas à l'origine avec ASP.NET Web Forms, car Web Forms ne veut pas du tout que vous regardiez le code HTML ou le script, sauf si vous vous devez vraiment, auquel cas , méfiez-vous, ce n'est pas pour les faibles de cœur.
Je suis un converti complet et total en ASP.NET MVC et je n'ai pas regardé en arrière, cela dit, je dois encore maintenir plusieurs très grandes applications WebForms. Voici mon point de vue:
Formulaires Web
Utilisez-les lorsque vous avez des charges lourdes importantes liées aux grilles. Les contrôles de grille sont vraiment très agréables lorsque vous disposez d'un ensemble de données simple qui s'intègre parfaitement dans un format tabulaire et que vous souhaitez fournir aux utilisateurs un moyen simple de mettre à jour les enregistrements. Oui, je sais que MVC 4 a une chose de type liste Ajax vraiment chic que vous pouvez utiliser qui fonctionne très bien mais, dans notre entreprise, nous devons souvent faire fonctionner quelque chose hier et de bonnes grilles à l'ancienne fonctionnent très bien et les utilisateurs sont heureux d'être capable de tabuler à travers une grille avec joie. Pour moi, c'est vraiment la meilleure chose à propos des WebForms pour moi; mais, comme Ryan l'a souligné, les formulaires Web peuvent être un gros gâchis parce que vous jouez des deux côtés de la clôture à partir d'un fichier code-behind astucieux. Il peut être à la fois une rose et une épine pour garder tous vos trucs de type contrôleur mélangés avec vos vues.
[~ # ~] mvc [~ # ~]
Utilisez-le lorsque vous voulez vraiment lancer le vôtre et que vous avez la possibilité de démarrer une application à partir de zéro. Avoir une application MVC clairement définie est un peu plus de travail pour commencer, mais ses avantages en termes de maintenabilité l'emportent sur le coût d'installation initial. Si vous voulez faire des interactions Ajax intéressantes, préférez écrire votre modèle avec du code, comme des URL et des itinéraires propres, et être en mesure de contrôler l'ensemble du flux de votre application, alors c'est certainement la voie à suivre. Il faut un certain temps pour s'y habituer, mais je pense que c'est la meilleure option pour les applications entièrement nouvelles.
En conclusion, pour moi, cela se résume aux grilles et! Grilles. :)
Mon expérience:
- A écrit des projets CakePHP pendant un an.
- Réalisation d'un projet de formulaires Web de taille moyenne sur six mois.
- A travaillé sur un projet Windows Forms pendant trois ans.
Après cette expérience, j'ai essayé d'écrire une autre application en utilisant des formulaires Web, et je suis frustré après avoir lutté pendant environ une journée avec la façon dont les formulaires Web tentent de protéger le développeur de la réalité qu'ils développent une application qui utilise html, javascript et css.
J'ai ensuite essayé MVC, et ayant un contrôle plus direct sur la sortie (et une certaine expérience avec le paradigme MVC de CakePHP), j'ai pu terminer cette application simple exactement comme je le voulais en environ 1/2 par jour.
La disponibilité de puissants frameworks d'interface utilisateur comme jQuery élimine largement l'attrait de renoncer au contrôle direct de la sortie au profit de l'utilisation de composants d'interface utilisateur pré-construits souvent encombrants.
Je préfère les formulaires Web parce que mon expérience est le développement de Windows.
La vitesse de développement est un problème clé, et je peux facilement passer un problème à quelqu'un en Inde pour le résoudre du jour au lendemain avec des formulaires, aussi, si j'ai un problème de vitesse sur une page, un très bon livre sur la vitesse asp.net est pratique (Rick Kiessig est l'homme).
webforms est pour ex windows personnes mvc est pour web personnes
mais, dans le monde moderne, où Rick a écrit un livre génial, avec des serveurs augmentant la vitesse quotidiennement et des codeurs bon marché en Inde, eh bien, les formulaires Web ont l'avantage
Mon 2 cents est de toujours utiliser ASP.NET MVC pour les nouveaux projets si vous en avez la possibilité. À mon avis, les formulaires Web ne sont pas un bon moyen de développer des applications Web, point final.
Je pense que l'abstrait de base REST est mauvais, le modèle de publication entier est mauvais, la façon dont html/css est remis en se fiant à l'éditeur GUI est mauvaise, l'accent sur des choses comme les assistants et les interfaces graphiques pour configurer des choses est mauvais, les URL sont mauvaises.
J'ai lu toutes les réponses et pense que mon expérience personnelle ajouterait quelque chose aux réponses ci-dessus.
3-4 ans en arrière, j'ai développé 2-3 projets de sites Web en utilisant des formulaires Web. À cette époque, MVC n'était pas là ou je n'en ai pas entendu parler. Le développement a été naturellement (je venais du développement de Win-forms sans expérience de développement Web) rapide pour moi, car je n'ai pas besoin d'apprendre le HTML dans les détails et les contrôles Web m'ont beaucoup aidé (beaucoup, cela a rendu la vie plus facile) .
Maintenant, après tout ce temps, je ne travaillais sur aucun projet Web jusqu'à récemment et je construisais simplement une application Windows à l'aide de WPF.
Il y a quelques jours, j'ai eu une idée pour un site Web et j'ai pensé à le développer: cette fois-ci dans MVC (car on en parle partout, en plus j'avais besoin d'apprendre non plus, alors j'ai choisi MVC). Le projet est toujours en phase de développement, car j'apprends et je construis toujours ensemble.
Ainsi, les principales différences que je trouve n/b les deux sont les suivantes: -
Pour quelqu'un qui vient du développement de Windows, les formulaires Web seront toujours favorables. La courbe d'apprentissage Asp.net pour un développeur Windows est un peu raide
Pour quelqu'un qui vient du développement Web dans une autre technologie, MVC sera favorisé car il se moque de la dernière de toutes.
Le développement est plus facile et plus propre dans MVC si vous avez une bonne connaissance de HTML et CSS
Le déploiement est toujours un problème. Dans les formulaires Web, il suffisait de faire du copier-coller. Mais, cela nécessite certaines choses à faire.
En bref, tous deux resteront ici pendant un certain temps.
Je n'ai pas encore vu cette considération mise en avant parmi les 15 réponses existantes à ce sujet, mais je pense que cela vaut la peine d'être considéré.
D'après mon expérience, Web Forms est plus similaire à Win Forms et WPF que MVC. Compte tenu de cela, je pense que l'on pourrait envisager de choisir des formulaires Web lorsque l'équipe a le plus d'expérience dans ce type de technologie, ou lorsque le projet Web Forms fournira une interface sur le même ensemble de données qu'un formulaire Win existant ou développé simultanément. Projet WPF. Cela permet aux développeurs de passer plus facilement d'un projet à l'autre, car la logique d'application peut être assez similaire entre les deux.
Comme d'autres réponses l'ont souligné, le développement sur le framework MVC est plus similaire au développement web en Ruby, PHP, Python etc que ses homologues Microsoft; donc naturellement le choix de MVC peut être influencé par le l'expérience des équipes dans ces domaines, ainsi que les facteurs présentés dans d'autres réponses.
Notre raison de ne pas être allé à MVC il y a quelques années était que c'était une technologie immature de Microsoft. Au cours des dernières années, nous sommes maintenant sur une version plus mature (4) et MS semble avoir déterminé où ils vont avec cela. Cependant, nous sommes toujours réticents à développer des applications LOB majeures à l'aide de MVC car les fonctionnalités que nous voulons utiliser dans la version 4 nécessitent un serveur Windows 2012 (concernant les sockets Web via IIS8). Je pense que dans 1 an de plus, nous accepterons davantage MVC car, espérons-le, plus de contrôles tiers seront disponibles, la technologie sera installée et nous disposerons de l'infrastructure pour la prendre en charge.
Cette décision dépend de vos préférences, de vos exigences ou même de vos connaissances et de votre expérience.
Le temps pour la formation d'apprentissage MVC ou le temps pour obtenir une livraison. Toutes ces choses comptent pour choisir l'une ou l'autre approche.
N'est-ce pas que l'un est meilleur qu'un autre, tout simplement les deux approches ou cadres ont des avantages et des inconvénients.
Personnellement, je préfère MVC 3, je vous recommande d'essayer d'obtenir votre propre expérience, mais je dois dire que le programme dans MVC est un moyen propre, amusant, flexible, extensible, sécurisé et structuré.
Cordialement,
La seule raison pour laquelle je choisirais les WebForms au lieu de MVC est que vous avez beaucoup plus de contrôles d'interface utilisateur tiers pour WebForms que MVC. J'ai choisi MVC parce que j'ai trop travaillé avec WebForms et je veux travailler avec quelque chose de nouveau/nouveau, mais toujours de MS shop :)
Fondamentalement, rien ne vous empêche de désactiver l'état d'affichage dans WebForms et d'utiliser ViewModels et les boucles if/for au lieu de la liaison de modèle et des contrôles côté serveur.
Est-ce le WebForms ou le code MVC:
<% foreach (var item in Model.Items) { %>
<p><%: item.Name %></p>
<% } %>
La seule limitation que j'ai trouvée dans WebForms est que si vous utilisez l'injection de dépendance/l'inversion de contrôle, vous ne pouvez pas avoir d'injection de constructeur car les pages WebForms doivent avoir un constructeur sans paramètre, vous devez donc utiliser l'injection de propriété. Est-ce vraiment un gros problème?
À mon avis, ils sont suffisamment liés et ont à peu près les mêmes capacités que cela devrait être préféré.
Un grand développeur WebForms peut produire un produit aussi puissant qu'un grand développeur MVC. Mais le grand développeur WebForms essayant de se forcer à adopter MVC va échouer. Il en va de même pour un grand développeur MVC qui donne un coup de pouce à WebForms.
Ce ne sont pas des entités complètement séparées, et tant que Microsoft continuera à prendre en charge les deux, je pense que vous continuerez à voir un groupe mixte de développeurs exceptionnels pour chacun.
ASP.NET MVC est vraiment une réponse à Ruby, et le nouveau moyen à la mode et (IMO) de découpler le navigateur (client) du serveur autant que possible.
ASP.NET Webforms vous donne beaucoup de contrôle sur le client du côté serveur, avec un accès direct à à peu près tout. Essentiellement, votre vue et votre contrôleur sont identiques, ce qui vous donne beaucoup de puissance et, la plupart du temps, beaucoup de dégâts.
ASP.NET MVC sépare la vue et le contrôleur en détachant le couplage étroit d'un fichier .aspx et du fichier .aspx.cs qui les accompagne dans les formulaires Web.
Essentiellement, la différence est d'avoir votre beaucoup plus (généralement la totalité) du traitement pour afficher les données dans le fichier de vue, et laisser la logique métier et le reste dans le contrôleur, en les gardant tous les deux plus propres par convention, mais aussi avec moins d'accès les uns aux autres que les formulaires Web ne le permettent.
Eh bien, WebForms a plus de ressources d'apprentissage disponibles (simplement parce qu'il est plus ancien) et donc les nouveaux programmeurs qui ne sont pas "au courant" seront plus susceptibles de trouver des informations concernant cette ancienne technologie par opposition aux trucs plus récents comme MVC .
Les programmeurs seniors/expérimentés sont plus âgés et seront plus compétents dans l'ancienne technologie en raison du fait qu'ils l'ont programmée plus longtemps que dans la nouvelle.
À moins que vous ne puissiez dépenser de l'argent et des efforts pour que vos gars soient aussi compétents en MVC que dans les applications WebForms, vous allez sans aucun doute essayer de retarder la mise à niveau vers la nouvelle plate-forme aussi longtemps que possible.
Il présente donc plusieurs problèmes logistiques: les avantages de MVC l'emportent-ils sur le coût en termes de moindre qualité et de temps de déploiement? Si j'ai un site entièrement écrit en WebForms, cela vaudrait-il la peine et l'effort d'y intégrer MVC?
Comme indiqué par un commentateur précédent, MVC vous empêche également d'atteindre le même niveau d'interface avec le contrôleur que vous le seriez avec WebForms. Bien que je sois tout à fait du côté "Empêcher l'utilisateur de bourrer les choses/d'apprendre", il peut toujours être excessivement gênant pour les équipes de déployer/mettre en œuvre un programme qui adhère fanatiquement à ce paradigme pour tout ce qu'elles écrivent.
Il s'agit de choix personnels, en supposant que nous maîtrisons tous la technologie que nous utilisons. J'utilise l'approche de conception WebForms depuis de nombreuses années, et je dois dire que le seul inconvénient est qu'en raison de son approche simpliste, beaucoup de gens ne prennent pas leur temps pour découvrir ses vastes capacités.
J'ai récemment utilisé MVC pour terminer un projet, et bien que j'apprécie beaucoup l'approche de conception pour le développement d'applications (qui vous donne plus de contrôle, des URL propres, SOC, etc.), il n'y a vraiment pas grand-chose qu'il offre, que WebForms ne peut pas. En fait, l'émergence de jQuery et de son fonctionnement avec WebForms (ainsi que MVC) a rendu ces arguments moins problématiques. Et lorsque les gens parlent de la séparation des préoccupations comme d'un avantage que MVC a sur MVP, je leur demande ce qu'ils savent de la programmation orientée objet et combien ils mettent en pratique le principe d'abstraction et de polymorphisme.
Je suis actuellement à l'aise avec les deux technologies et je choisis en fonction de la situation. Franchement, cela dépend de vous, mais la vérité demeure que tout le monde ne prend pas son temps pour apprendre en profondeur de quoi une technologie particulière est capable.
Face à un problème de programmation, je cherche souvent des réponses sur le Web. Webforms a des tonnes d'informations/composants sur à peu près tout. Dans MVC en raison de moins de sources en ligne et des couches d'abstractions nécessaires pour que quelque chose fonctionne, j'ai mis une limite aux choses que je pouvais faire une fois. MVC total tue ma productivité en tant que développeur alors qu'avec Webforms ce n'est pas le cas. Donc, pour l'instant, je m'en tiens aux formulaires Web jusqu'à ce que MVC ait suffisamment mûri pour le remplacer.