Par rapport aux Formulaires Web, MVC est à la fois un niveau inférieur à l'approche de la génération HTML avec un plus grand contrôle sur la sortie de la page et un niveau plus élevé, plus l'architecture. Permettez-moi de capturer des Formulaires Web et MVC et de montrer pourquoi je pense que la comparaison des faveurs de Formulaires Web dans de nombreuses situations - tant que vous ne tombez pas dans certains Formulaires Web classique pièges.
Des Formulaires Web
Dans le modèle de Formulaires Web, vos pages correspondent directement à la demande de page à partir du navigateur. Ainsi, si vous êtes dirigeant d'un utilisateur à une liste de Livres, vous aurez probablement une page quelque part appelée "liste compilée.aspx" à laquelle vous allez vous diriger. Dans cette page, vous devez fournir tout le nécessaire pour afficher cette liste. Cela comprend le code pour l'extraction de données, en appliquant une logique métier, et d'afficher les résultats. Si il y a tout de l'architecture ou de la logique de routage qui affectent la page, vous aurez le code de la logique architecturale sur la page. De bonnes Formes de Web développement implique généralement le développement d'un ensemble de classes de support dans un document distinct (unité-testable) DLL. Ces classe(s) de la poignée de la logique métier, accès aux données et de l'architecture et des décisions de routage.
MVC
MVC est plus "architectural" de développement d'applications web: en proposant un standardisé échafaudage sur lequel construire. Il fournit également des outils pour la génération automatique de modèle, vue et contrôleur de classes dans l'architecture. Par exemple, dans les deux Ruby on Rails (juste des "Rails" à partir de maintenant) et ASP.NET MVC, vous allez toujours commencer avec une structure de répertoire qui reflète l'ensemble de leur modèle d'architecture d'application web. Pour ajouter une vue, le modèle et le contrôleur, vous devez utiliser une commande comme des Rails de "Rails script/generate scaffold {nom du modèle}" (ASP.NET MVC offre des commandes similaires dans l'IDE). Dans le contrôleur de classe, il y aura des méthodes (les"Actions") pour les Index (voir la liste), de Montrer, de Nouvelles et de les Éditer et de les Détruire (au moins dans les Rails, MVC est similaire). Par défaut, ces "Obtenir" des Actions en écrivant le Modèle et la voie à une vue correspondante/un fichier html dans le "View/{nom du modèle}" directory (à noter qu'il existe aussi Créer, mettre à Jour et de Détruire des actions de traiter un "Post" et itinéraire vers de l'Indice ou de Spectacle).
La mise en page des répertoires et des fichiers est importante dans MVC. Par exemple, dans ASP.NET MVC, l' Indice de la méthode pour un "Livre objet" sera probablement juste une ligne: "Return View();" Par la magie de la MVC, cela enverra le Livre de modèle à l' "/View/Livres/Index.aspx" page où vous trouverez le code pour afficher les Livres. Rails de l'approche est similaire, bien que la logique est un peu plus explicite et moins de "magie". Une Vue de la page dans une application MVC est généralement plus simple qu'une page Web Forms, car ils n'ont pas à s'inquiéter autant de routage, la logique d'affaires ou de traitement des données.
Comparaison
Les avantages de la MVC tournent autour d'une séparation des préoccupations et un environnement plus propre, plus HTML/CSS/AJAX/Javascript centrée sur le modèle de la production de votre sortie. Cela améliore la capacité de test, offre une meilleure conception normalisée et ouvre la porte à un plus "Web 2.0", le type de site web.
Cependant, il ya certains inconvénients aussi bien.
Tout d'abord, alors qu'il est facile d'obtenir un site de démonstration, l'ensemble architectural modèle a une courbe d'apprentissage importante. Quand ils disent "Convention Over Configuration", ça sonne bien - jusqu'à ce que vous vous rendez compte que vous avez un livre de valeur de la convention d'apprendre. En outre, c'est souvent un peu exaspérant de comprendre ce qui se passe parce que vous êtes en s'appuyant sur la magie plutôt que des appels explicites. Par exemple, que "Return View();" l'appel ci-dessus? Exactement le même appel peut être trouvé dans d'autres Actions, mais ils vont à des endroits différents. Si vous comprenez le MVC convention alors vous savez pourquoi c'est fait. Cependant, il n'est certainement pas considéré comme un exemple de bon de nommer ou de facilement compréhensible par le code, et il est beaucoup plus difficile pour les nouveaux développeurs pour ramasser que des Formulaires Web (ce n'est pas seulement l'opinion: j'ai eu un stage d'été à apprendre des Formulaires Web l'année dernière et MVC cette année, et les différences de productivité ont été prononcées en faveur de Formulaires Web). BTW, Rail est un peu mieux, à cet égard, bien que Ruby on Rails fonctions dynamiquement nommé méthodes qui prennent un certain sérieux se-servir-de.
Deuxièmement, MVC suppose implicitement que vous êtes la construction d'un classique CRUD de style de site web. Les décisions en matière d'architecture et en particulier les générateurs de code sont tous construits pour soutenir ce type d'application web. Si vous êtes à la construction d'une application CRUD et à adopter une architecture éprouvée (ou simplement aversion pour la conception de l'architecture), alors vous devriez probablement envisager MVC. Toutefois, si vous allez faire plus de CRUD et/ou vous êtes assez compétent en architecture puis MVC peut se sentir comme une camisole de force jusqu'à ce que vous avez vraiment maître de la sous-jacentes de routage modèle (qui est beaucoup plus complexe que de simplement le routage dans une application web forms). Même alors, j'ai senti comme si j'étais toujours en lutte le modèle et inquiet des résultats inattendus.
Troisièmement, si vous n'avez pas de soins pour Linq (soit parce que vous avez peur que Linq-to-SQL est en train de disparaître ou parce que vous trouvez Linq-to-Entités laughably sur-produit et sous tension), alors vous ne voulez pas marcher sur ce chemin depuis ASP.NET MVC échafaudage outils sont construits autour de Linq (ce qui était le tueur pour moi). Les Rails du modèle de données est également assez maladroit par rapport à ce que vous pouvez obtenir si vous avez de l'expérience en SQL (et surtout si vous êtes bien versé dans TSQL et des procédures stockées!).
Quatrièmement, MVC partisans soulignent souvent qu'MVC points de vue sont plus proches dans l'esprit de l'HTML/CSS/AJAX modèle de la web. Par exemple, "HTML Helpers" - les appels de code dans votre vew page de swap dans le contenu et de le placer dans le HTML les contrôles sont beaucoup plus facile à intégrer avec Javascript que les contrôles de Formulaires Web. Cependant, ASP.NET 4.0 introduit la possibilité de nommer vos commandes et ainsi élimine en grande partie de cet avantage.
Cinquième, MVC puristes souvent moque de Viewstate. Dans certains cas, ils sont en droit de le faire. Cependant, l'état d'affichage peut aussi être un formidable outil et un atout pour la productivité. À titre de comparaison, la manipulation de l'état d'affichage est beaucoup plus facile que d'essayer d'intégrer tiers des contrôles web dans une application MVC. Tandis que le contrôle de l'intégration peut être plus facile pour MVC, tous les efforts que j'ai vu souffrir de la nécessité de construire (un peu grody) code de liens entre ces contrôles à la vue du Contrôleur de classe (c'est - à contourner le modèle MVC).
Conclusions
J'aime MVC développement de plusieurs façons (bien que je préfère les Rails ASP.NET MVC par un long shot). Je pense aussi que c'est important pour nous de ne pas tomber dans le piège de penser que l'ASP.NET MVC est un "anti-modèle" de ASP.NET les Formulaires Web. Elles sont différentes mais pas complètement étranger et il ya certainement de la place pour les deux.
Cependant, je préfère les Formes de Web développement, car, pour la plupart des tâches, il est simplement plus facile de faire les choses (l'exception étant la génération d'un ensemble de CRUD formes). MVC semble aussi souffrir, dans une certaine mesure, à partir d'un excès de théorie. En effet, regardez le nombre de questions posées ici par des gens qui savent orientées page ASP.NET mais qui tentent MVC. Sans exception, il y a beaucoup de grincements de dents que les développeurs trouvent qu'ils ne peuvent pas effectuer des tâches de base sans sauter à travers des cerceaux ou durable d'un énorme courbe d'apprentissage. C' est ce qui rend les Formulaires Web de qualité supérieure pour MVC dans mon livre: MVC vous fait payer un monde réel prix afin de gagner un peu plus de testabilité ou, pire encore, à être simplement considéré comme cool parce que vous êtes à l'aide de la technologie la plus récente.
Mise à jour: j'ai été critiqué fortement dans la section des commentaires, en partie tout à fait juste. Ainsi, j'ai passé plusieurs mois à apprendre Rails et ASP.NET MVC juste pour s'assurer que je n'étais pas vraiment absent dehors sur la prochaine grande chose! Bien sûr, il permet également de s'assurer que je donne un équilibre et une réponse appropriée à la question. Vous devez savoir que la réponse ci-dessus est une réécriture majeure de mon début de réponse dans le cas où les commentaires semblent désynchronisés.
Alors que j'étais à la recherche de plus près MVC, j'ai pensé que, pour un peu de temps, que je finirais avec un grand mea culpa. En fin de compte j'en ai conclu que, bien que je pense que nous avons besoin de dépenser beaucoup plus d'énergie sur des Formulaires Web de l'architecture et de la testabilité, MVC n'a vraiment pas de répondre à l'appel pour moi. Donc, un chaleureux "merci" pour les gens qui ont fourni intelligent critiques de ma première réponse.
Pour ceux qui ont vu cela comme un religieux de bataille et qui n'ont de cesse d'ingénierie downvote inondations, je ne comprends pas pourquoi vous vous donnez la peine (20+ bas-voix à l'intérieur de secondes l'un de l'autre, à plusieurs reprises, n'est certainement pas normal). Si vous êtes à la lecture de cette réponse et je me demandais si il y a quelque chose de "mal" à propos de ma réponse étant donné que le score est beaucoup plus faible que celle de certains autres réponses, soyez assuré qu'il en dit plus sur quelques personnes qui sont en désaccord que le sens général de la communauté (en général, celui-ci a été upvoted plus de 100 fois).
Le fait est que beaucoup de développeurs ne se soucient pas de MVC et, en effet, ce n'est pas un point de vue minoritaire (même à l'intérieur de MME que les blogs semblent indiquer).
