Pourquoi utiliser MVC sur le Web Forms?

Question

Récemment, un architecte décrit notre société en offrant une solution Rolls-Royce (MVC) quand tout ce qu'il avait besoin était une Toyota (Web Forms).

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

Answer 1

L'analogie Rolls-Royce / Toyota est terriblement erronée et trompeuse. Un (ASP.NET MVC) n'est pas simplement une version colombophile ou plus cher de l'autre (ASP.NET WebForms). Ils sont des approches très différentes pour la création d'applications Web avec ASP.NET.

Pour moi, la plus grande différence architecturale entre MVC et WebForms est de savoir comment ils travaillent avec l'environnement sans état du web: WebForms travaille dur pour construire un ensemble d'abstractions qui cachent la nature sans état de la programmation web, alors que MVC embrasse l'environnement sans état et travaille avec elle.

Chaque approche a ses avantages et inconvénients, mais j'aime vraiment comment créer des sites web avec MVC se sent beaucoup plus naturel que WebForms (avec son couche sur couche d'abstraction qui fuit ).

Answer 2

question ancienne mais il mérite une personne réponse plus détaillée que dans des cas d'autre là-bas est encore avoir fait un dilemme dessus.

En fin de compte, est une solution webforms client léger par lequel il est signifié que vous appuyez sur un tas de jolis boutons et l'extrémité avant (client) est construit des choses pour vous. Si vous avez des gens qui savent tourner la manivelle dans webforms et il n'y a absolument aucun maintenabilité / préoccupations de Modifiabilité et le site est complètement à court terme et à usage unique, il n'y a rien du tout mal avec cette approche. Il est possible d'apprendre à faire vos propres trucs, mais dans ce cas il faudrait connaître les trucs web WebForms tente de protéger les développeurs d'applications .NET de et tous les trucs WebForms qui rend la plupart des développeurs web du côté client veulent assassiner Microsoft ingénieurs responsables.

Dans le 99,5% de tous les autres scénarios de cas d'utilisation, nous avons cessé d'essayer de cacher le web des développeurs d'applications parce que vraiment, si vous voulez web write applications êtes beaucoup mieux apprendre réellement comment fonctionne le Web. L'ironie épaisse vs mince solutions client est qu'inévitablement l'approche client léger gonflerait inévitablement la merde hors de votre extrémité avant et est tout sauf performant. Plus important encore, ces solutions ont toujours fait des choses rigides que tout l'enfer pour les gens qui savent vraiment ce qu'ils font et ne veulent pas être limités par le cadre en vigueur.

Il n'y a rien si inutile que de prendre quelqu'un qui sait tout sur CSS, JavaScript, HTML, XHR et en les rendant totalement inutile en les roadblocking à chaque étape du chemin avec un cadre ...

• vous permet de supprimer tous les tags de script « » inutiles dans les balises de tête pour vous empêcher de vissage sur les dépendances de script. (Mieux de laisser une poignée « gestionnaire de script » pour vous), met Accordée personne ne « em up là-bas aujourd'hui s'ils savent ce qu'ils font, mais qui vient foiré.

• vous enveloppez Insiste tous le HTML dans une balise form ginormous. HTML ne permet pas à l'intérieur de formes formes si vous faites la façon dont les formes WebForms ou rien du tout.

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

• ne fait tout ce qu'il peut pour obtenir de la manière d'utiliser des solutions non-WebForms aux problèmes. Exemple: Quand j'étais un côté client plus junior dev J'ai passé toute une journée à trouver un moyen de faire un bouton d'envoi en haut de la gâchette de la page un bouton soumettre au bas d'une page (je suppose en raison de ce que l'un-Big- chose forme géante). Normalement, cela prendrait 5 minutes, mais après tout à fait quelques heures l'ingénierie inverse des webforms JavaScript responsables, j'ai découvert qu'ils étaient entre autres définition d'une propriété que je ne connaissais même pas au moment où vous indique ce que le dernier élément de formulaire pour avoir accent bouton a été de sorte que quand un bouton d'envoi a été cliqué, seul le officiel de Microsoft Submit (tm) travaillerait en ce qui concerne l'activation d'un gestionnaire officiel de Microsoft Submit (tm).

Donc non, Rolls-Royce vs Toyota, est tout à fait déraisonnable. Je dirais plus, une Hyundai tout à fait raisonnable que vous payez trop cher pour contre Microsoft conçu Pinto avec un système embarqué qui effectue automatiquement des virages serrés à 90 degrés quand il découvre que vous avez acheté du gaz ou de l'huile de quelqu'un d'autre que Microsoft et il y a détecté une mur pratique pour percutent. Une voiture idéale pour le conducteur fidèle marque qui suicidairement ne sait rien sur le web et veut jurer fidélité à vie à Microsoft.

Tout .NET MVC est vraiment, est simple et raisonnable, et il ne réinvente pas sa propre couche de claque au-dessus de la bande. Il fonctionne avec ce qui est là pouraide assommer un peu passe-partout pour vous. Il est mieux / moins cher / cadres sans ouvertures disponibles, mais si vous avez déjà vous enfermé dans la chose .NET, vous pourriez faire bien pire.

Mais sérieusement, rester le! @ # $ Loin de webforms. Il est maintenant presque mort. Laisser aller. Faites savoir à vos clients que vous allez le faire trois fois l'argent si elles promettent aussi vous un by-the-heure contrat de soutien exclusif et lucratif pour quand ils veulent vraiment faire quelque chose de nouveau ou de différent ou quand merde commence casser parce que même pas MS pourrait être pris la peine de continuer à ajouter à ce mastodonte d'un fichier ajax.js ligne 10 000 ils tirent de leur cul DLL où vous ne pouvez pas le toucher.

Answer 3

Une solution ASP.NET MVC ne doit pas être plus compliqué qu'une solution WebForms. Personnellement, je trouve ASP.NET MVC être en fait beaucoup plus simple que WebForms, et il semble certainement être intrinsèquement plus propre.

D'après mon expérience, beaucoup de frameworks MVC (ASP.NET, Rails, CodeIgniter, etc.) ont une grande partie de la même fonctionnalité de base et les conventions. WebForms est vraiment le canard étrange d'un point de vue web. Je suppose la plupart des programmeurs web serait beaucoup plus rapide à ramasser ASP.NET MVC que WebForms.

Answer 4

La raison supérieure que vous utilisez ASP.NET MVC sur ASP.NET WebForms est testabilité. Bien sûr, vous pouvez sorte de WebForms de tests unitaires, mais cela nécessite des cadres et se moquant d'une douleur beaucoup. La deuxième raison est MVC ne fait un peu plus facile pour séparer les préoccupations. Cela peut fournir une grande quantité de réutilisation de code et rendre votre code à couplage lâche. Cela ne veut pas dire qu'il est impossible de faire la même chose dans ASP.NET avec des motifs comme MVP.

L'inconvénient de MVC est que vous perdez beaucoup de la fonctionnalité et qui a été construit en WebForms au cours de la dernière décennie (ou presque). MVC a parcouru un long chemin depuis sa création à fonctions fournies similiar.

En ce qui concerne la performance, quelqu'un at-il une preuve d'une façon ou une autre dont la technologie est « plus rapide »?

Je ne pense pas que l'un est meilleur que l'autre. Je fais vraiment comme le framework MVC et ont utilisé avec grand succès, mais je fais toujours sûr que je choisis la technologie qui correspond au projet.