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.