En savoir plus sur les différences entre ASP.NET MVC et WebForm

Parlez de la différence entre ASP.NET MVC et WebForm

En utilisant le framework ASP.NET MVC pour créer un projet par défaut, le premier sentiment intuitif est que les adresses sont toutes réécrites . Après une légère analyse du code source et des fichiers de configuration, il n'est pas difficile de voir que MVC utilise httpModules pour intercepter les demandes d'adresse, notamment en utilisant la bibliothèque de classes System.Web.Routing (dans MVC2, j'ai oublié comment utiliser MVC1.) et cette partie de la bibliothèque de classes est packagée dans .NET Framework3.5 SP1, il est naturel que MVC2 nécessite la prise en charge de SP1. La bibliothèque de classes System.Web.Routing fournie par SP1 peut facilement intercepter les demandes d'adresse et est également excellente dans le traitement de l'encodage. La classe UrlRoutingModule intercepte les requêtes. Avant cela, lors de Application_Start, un paramètre d'interception sera donné à l'objet global de RouteTable. Ce paramètre est enregistré à l'aide de l'objet RouteCollection et MVC étend cette classe - RouteCollectionExtensions. Ceux-ci peuvent être ignorés. Ensuite, lorsque l'utilisateur accède à la page, la classe UrlRoutingModule intercepte la requête et vérifie dans le RouteTable si elle respecte les règles. Si c'est le cas, MvcHandler sera appelé. Cet appel est enregistré dans le nœud de configuration httpHandlers. à condition que l'adresse corresponde aux règles "* .mvc". La méthode ProcessRequest de MvcHandler appellera le contrôleur pour s'exécuter. En fait, l’ensemble du processus est une boîte noire et les utilisateurs ne peuvent pas le ressentir. Une fois qu'une méthode est exécutée dans le contrôleur, le résultat est renvoyé, puis la page aspx spécifique est saisie.

Après avoir analysé le projet de travail de MVC, vous pouvez comparer sa différence avec WebForm. Nous savons que les activités en mode MVC sont placées dans le contrôleur pour exécution et que la page aspx est uniquement responsable de l'affichage. Ensuite, le temps d'exécution réel de l'entreprise dans MVC est avancé vers HttpMolde et la requête WebForm n'est exécutée que dans le conteneur httpHandler. En d'autres termes, la séparation du contrôleur et de la vue dans MVC est obtenue en utilisant le pipeline de requêtes ASP.Net. De cette manière, le niveau logique du code est sans aucun doute atteint sans affecter l'efficacité (une requête, tandis que Response.Redirect est une). deuxième demande).

Les avantages du travail MVC sont évidents, il est plus propice à la compréhension de la logique en couches et à la compréhension des couches du code. Le processus entre le contrôleur et la page aspx a été isolé par le framework. Quant au processus d'appel de la page Contrôleur ou Vue et du Modèle, vous devez toujours le maîtriser vous-même. Le framework MVC d'ASP.NET implémente une gestion séparée du code du contrôleur.

En regardant le modèle de développement WebForm , il n'est exécuté que dans le conteneur HttpHandler et en couches. Il manque de support dans de grands aspects et ne peut s'appuyer que sur une séparation logique. Ce n’est pas qu’ils ne puissent pas être séparés, mais qu’ils ont certaines limites. L'interception de HttpHandler est liée à l'accès au nom du suffixe. Lorsqu'une page est demandée, il s'agit d'un gestionnaire, et le modèle WebForm réalise la séparation de l'affichage et de la logique, et seul l'événement de WinForm est disponible. Évidemment, l'événement doit être enregistré sur la page, comme le code Button1_Click. Avant l'exécution de Button1_Click, la méthode Page_Load sera exécutée.

Le code d'affichage est écrit dans la méthode Page_Load, ce qui entraînera la nécessité d'écrire du code de gaspillage supplémentaire, tel que if (!Page.IsPostBack). La partie qui doit être affichée après l'exécution de Button1_Click est plus difficile à gérer. L'écriture d'une autre méthode doit également être appelée dans Button1_Click. La solution alternative consiste à utiliser Response.Redirect, à traiter la logique dans une page aspx et à passer à une autre page affichée après le traitement. L'inconvénient est qu'il est difficile de partager les données entre les deux pages, et le saut est implémenté par le marquage 302, il y a donc une requête supplémentaire. De plus, grâce à des méthodes de traitement telles que Server.Execute, Server.Transfer ou Context.RewritePath, la conversion des deux pages s'effectue côté serveur et les données peuvent être partagées. On peut dire que la méthode de traitement est similaire à celle-là. du framework MVC. L'inconvénient est que cela doit être fait manuellement.

D'après l'analyse ci-dessus, nous pouvons voir que le framework MVC présente de forts avantages, et WebForm n'est pas sans mérite et est plus facile à développer dans des applications simples. WebForm peut également implémenter la même méthode de superposition que MVC, mais vous devez écrire plus de code lors du traitement. À mon avis, le plus gros problème rencontré lors de l'utilisation de WebForm pour développer un développement hiérarchique est le transfert de données entre les pages, et la maîtrise des compétences applicatives liées à l'utilisation des sauts côté serveur dans WebForm (Server.Execute, Server.Transfer ou Context. RewritePath) peut Résolvez le problème de transmission de données. Comparé à ASP.NET MVC et WebForm, WebForm est plus facile à comprendre et ne produit pas de configurations compliquées.

【Recommandations associées】

1. Qu'est-ce qu'ASP.NET MVC ? Résumé d'ASP.NET MVC

2 Introduction détaillée au contrôleur ASP.NET MVC

3. Introduction détaillée à ASP.NET MVC--Vue

4 Introduction détaillée à ASP.NET MVC--Routage

5 .

Exemple de code pour développer un outil d'édition de menu personnalisé WeChat via asp.net mvc

Ce qui précède est le contenu détaillé de. pour plus d'informations, suivez d'autres articles connexes sur le site Web de PHP en chinois!