Pourquoi utiliseriez-vous MVC sur des formulaires Web?

Récemment, un architecte a décrit notre entreprise comme offrant une solution Rolls-Royce (MVC) alors qu'il n'avait besoin que d'une Toyota (Web Forms).

Je suis curieux de savoir ce que vous pensez des formulaires Web vs MVC en tant que choix architectural.

L'analogie Rolls-Royce / Toyota est terriblement imparfaite et trompeuse. L'un (ASP.NET MVC) n'est pas simplement une version plus sophistiquée ou plus chère de l'autre (ASP.NET WebForms). Ce sont des approches très différentes pour créer des applications Web à l'aide d'ASP.NET.

Pour moi, la plus grande différence architecturale entre MVC et WebForms est la façon dont ils fonctionnent avec l'environnement sans état du Web: WebForms travaille dur pour créer un ensemble d'abstractions qui masquent la nature sans état de la programmation Web, tandis que MVC embrasse l'environnement sans état et travaille avec il.

Chaque approche a ses avantages et ses inconvénients, mais j'apprécie vraiment la façon dont la création de sites Web avec MVC semble beaucoup plus naturelle que WebForms (avec sa couche sur couche d'abstractions qui fuient ).

Vieille question, mais elle mérite une réponse plus détaillée au cas où quelqu'un d'autre aurait toujours un dilemme à ce sujet.

En fin de compte, les formulaires Web sont une solution de client léger, ce qui signifie que vous appuyez sur un tas de jolis boutons et que les éléments frontaux (client) sont conçus pour vous. Si vous avez des gens qui savent comment le lancer dans les formulaires Web et qu'il n'y a absolument aucun problème de maintenabilité / modifiabilité et que le site est complètement à court terme et jetable, il n'y a rien de mal à cette approche. Il est possible d'apprendre à faire vos propres trucs, mais dans ce cas, cela nécessiterait de connaître à la fois les trucs Web que les formulaires Web essaient de protéger. ingénieurs responsables.

Dans 99,5% de tous les autres scénarios de cas d'utilisation, nous avons cessé d'essayer de cacher le Web aux développeurs d'applications parce que vraiment, si vous voulez écrire des applications Web, vous êtes beaucoup mieux en train d'apprendre le fonctionnement du Web. L'ironie des solutions client léger vs client léger est que, inévitablement, l'approche client léger alourdit inévitablement la merde de votre partie avant et est tout sauf performante. Plus important encore, ces solutions ont toujours rendu les choses inflexibles comme tout l'enfer pour les personnes qui savent réellement ce qu'elles font et ne veulent pas être contraintes par le cadre en vigueur.

Il n'y a rien de plus inutile que de prendre quelqu'un qui sait tout sur CSS, JavaScript, HTML, XHR et de les rendre complètement inutiles en les bloquant à chaque étape du chemin avec un cadre qui ...

• Efface toutes les balises de script «inutiles» dans les balises head pour vous empêcher de bousiller les dépendances de script. (mieux vaut laisser un 'gestionnaire de scripts' s'en occuper pour vous) Certes, personne ne les met là-haut de nos jours s'ils savent ce qu'ils font mais c'est juste foiré.

• Insiste pour que vous enveloppiez tout le code HTML dans une seule balise de formulaire ginormous. HTML n'autorise pas les formulaires à l'intérieur des formulaires, vous faites donc les formulaires à la manière des formulaires Web ou pas du tout.

• Crée comme un "cycle de vie" en 18 étapes pour ce qui devrait vraiment se résumer à réagir aux événements de l'interface utilisateur en interagissant avec le navigateur pour envoyer des messages au serveur, puis réagir lorsque le serveur répond. Abstraire ce processus avec un gros tas d'ordures géant n'a jamais eu besoin de se produire (et pour être juste, MS n'est pas le seul crétin qui a essayé de le faire).

• Effectue en fait tout ce qu'il peut pour empêcher l'utilisation de solutions non Webforms aux problèmes. Exemple: lorsque j'étais un développeur côté client plus junior, j'ai passé une journée entière à trouver un moyen de faire en sorte qu'un bouton d'envoi en haut de la page déclenche un bouton d'envoi en bas d'une page (je suppose en raison de cette taille unique) chose de forme géante). Normalement, cela prendrait 5 minutes, mais après quelques heures de rétro-ingénierie des formulaires Web responsables de JavaScript, j'ai découvert qu'ils définissaient entre autres une propriété que je ne connaissais même pas à l'époque qui vous indiquait quel était le dernier élément du formulaire à avoir l'accent était mis sur le fait que lorsqu'un bouton d'envoi était cliqué, seul le bouton officiel Microsoft Submit (tm) fonctionnerait en ce qui concerne l'activation d'un gestionnaire officiel Microsoft Submit (tm).

Donc non, Rolls-Royce vs Toyota, est complètement déraisonnable. Je dirais plus, une Hyundai parfaitement raisonnable pour laquelle vous payez beaucoup trop par rapport à un Pinto conçu par Microsoft avec un système intégré qui effectue automatiquement des virages serrés à 90 degrés lorsqu'il découvre que vous avez acheté du gaz ou du pétrole à quelqu'un d'autre que Microsoft et qu'il a détecté un mur pratique à claquer. Une voiture idéale pour le conducteur fidèle à la marque suicidaire qui ne sait rien du Web et veut jurer fidélité à Microsoft à vie.

Tout .NET MVC est vraiment, est simple et raisonnable, et il ne réinvente pas sa propre couche pour gifler sur le Web. Cela fonctionne simplement avec ce qui est là pour vous aider à éliminer un passe-partout pour vous. Il existe de meilleurs frameworks / moins chers / plus libres, mais si vous vous êtes déjà enfermé dans le truc .NET, vous pourriez faire bien pire.

Mais sérieusement, éloignez le! @ # $ Des formulaires Web. Il est presque mort maintenant. Laisser aller. Dites à vos clients que vous le ferez pour trois fois l'argent s'ils vous promettent également un contrat de support exclusif et lucratif à l'heure pour quand ils veulent réellement faire quelque chose de nouveau ou de différent ou quand la merde commence à se briser parce que même MS ne pourrait pas être gêné de continuer à ajouter à ce monstre d'un fichier ajax.js de 10 000 lignes qu'ils tirent de leur cul de DLL où vous ne pouvez pas le toucher.

Une solution ASP.NET MVC n'a pas besoin d'être plus compliquée qu'une solution WebForms. Personnellement, je trouve que ASP.NET MVC est en fait beaucoup plus simple que WebForms, et il semble définitivement plus propre.

D'après mon expérience, de nombreux frameworks MVC (ASP.NET, Rails, CodeIgniter, etc.) ont pratiquement les mêmes fonctionnalités et conventions de base. WebForms est vraiment le canard étrange d'un point de vue Web. Je suppose que la plupart des programmeurs Web seraient beaucoup plus rapides à choisir ASP.NET MVC que WebForms.

La principale raison pour laquelle vous utiliseriez ASP.NET MVC sur ASP.NET WebForms est la testabilité. Bien sûr, vous pouvez en quelque sorte tester les WebForms de manière unitaire, mais cela nécessite des frameworks moqueurs et beaucoup de peine. La deuxième raison est MVC ne fait un peu plus facile à des préoccupations distinctes. Cela peut fournir beaucoup de réutilisation de code et rendre votre code faiblement couplé. Cela ne signifie pas qu'il est impossible de faire de même dans ASP.NET avec des modèles comme MVP.

L'inconvénient de MVC est que vous perdez beaucoup de fonctionnalités et cela a été intégré dans WebForms au cours de la dernière décennie (enfin presque). MVC a parcouru un long chemin depuis sa création pour fournir des fonctionnalités similaires.

En ce qui concerne les performances, quelqu'un a-t-il une preuve d'une manière ou d'une autre de quelle technologie est "plus rapide"?

Je ne pense pas que l'un soit meilleur que l'autre. J'aime vraiment le framework MVC et je l'ai utilisé avec beaucoup de succès mais je m'assure toujours de choisir la technologie qui correspond au projet.