Site Web ASP.NET ou application Web ASP.NET?
Lorsque je démarre un nouveau projet ASP.NET dans Visual Studio, je peux créer une application Web ASP.NET ou un site Web ASP.NET.
Quelle est la différence entre une application Web ASP.NET et un site Web ASP.NET? Pourquoi devrais-je choisir un sur l'autre?
La réponse est-elle différente en fonction de la version de Visual Studio que j'utilise?
Site Web:
Le projet de site Web est compilé à la volée. Vous vous retrouvez avec beaucoup plus de fichiers DLL, ce qui peut être pénible. Cela pose également des problèmes lorsque vous avez des pages ou des contrôles dans un répertoire qui doivent référencer des pages et des contrôles dans un autre répertoire, car l'autre répertoire peut ne pas encore être compilé dans le code. Un autre problème peut être dans l'édition.
Si Visual Studio n'est pas invité à réutiliser les mêmes noms de manière constante, il créera de nouveaux noms pour les fichiers DLL générés par des pages tout le temps. Cela peut conduire à avoir plusieurs copies proches de DLL fichiers contenant le même nom de classe, ce qui générera de nombreuses erreurs. Le projet de site Web a été introduit avec Visual Studio 2005, mais il n’est pas très populaire.
Application Web:
Le projet d'application Web a été créé en tant que complément et existe maintenant dans le cadre de SP 1 pour Visual Studio 2005. Les principales différences sont le projet d'application Web. a été conçu pour fonctionner de manière similaire aux projets Web fournis avec Visual Studio 2003. Il compilera l’application dans un seul fichier DLL lors de la génération. Pour mettre à jour le projet, il doit être recompilé et le fichier DLL publié pour que des modifications puissent être apportées.
Une autre fonctionnalité intéressante du projet d'application Web est qu'il est beaucoup plus facile d'exclure des fichiers de la vue du projet. Dans le projet de site Web, chaque fichier que vous excluez est renommé avec un mot clé exclu dans le nom du fichier. Dans le projet d'application Web, le projet ne fait que garder une trace des fichiers à inclure/exclure de la vue du projet sans les renommer, ce qui rend les choses beaucoup plus ordonnées.
L'article ASP.NET 2.0 - Projet d'application de site Web ou d'application Web donne également les raisons pour lesquelles utiliser l'un et pas l'autre. En voici un extrait:
- Vous devez migrer de grandes applications Visual Studio .NET 2003 vers VS 2005? utilise le projet d'application Web.
- Vous souhaitez ouvrir et modifier n'importe quel répertoire en tant que projet Web sans créer de fichier de projet? utilise le projet de site Web.
- Vous devez ajouter des étapes de pré-génération et de post-génération lors de la compilation? utilise le projet d'application Web.
- Vous devez créer une application Web à l'aide de plusieurs projets Web? utilise le projet d'application Web.
- Vous souhaitez générer un assemblage pour chaque page? utilise le projet de site Web.
- Vous préférez la compilation dynamique et le travail sur les pages sans créer un site entier sur chaque affichage de page? utilise le projet de site Web.
- Vous préférez un modèle de code d'une seule page à un modèle de code après code? utilise le projet de site Web.
Projets d'application Web et projets de site Web (MSDN) explique les différences entre les projets de site Web et d'applications Web. En outre, il explique la configuration à effectuer dans Visual Studio.
Site Web est ce que vous déployez sur un serveur Web ASP.NET tel que IIS. Juste un tas de fichiers et de dossiers. Aucun site Web ne vous lie à Visual Studio (aucun fichier de projet). La génération de code et la compilation de pages Web (telles que .aspx, .ascx, .master) sont effectuées dynamiquement à l'exécution , et les modifications apportées à ces fichiers sont détectées par le framework et automatiquement recompilées. Vous pouvez mettre le code que vous souhaitez partager entre les pages dans le dossier spécial App_Code, ou vous pouvez le pré-compiler et placer l'Assemblée dans le dossier Bin.
Application Web est un projet spécial de Visual Studio. La principale différence avec les sites Web est que, lorsque vous générez le projet, tous les fichiers de code sont compilés dans un seul assembly, qui est placé dans le répertoire bin. Vous ne déployez pas de fichiers de code sur le serveur Web. Au lieu d’avoir un dossier spécial pour les fichiers de code partagés, vous pouvez les placer n’importe où, comme dans une bibliothèque de classes. Les applications Web contenant des fichiers non destinés à être déployés, tels que des fichiers de projet et des fichiers de code, il existe une commande Publier dans Visual Studio permettant d'afficher un site Web à un emplacement spécifié.
App_Code vs Bin
Le déploiement de fichiers de code partagés est généralement une mauvaise idée, mais cela ne signifie pas que vous deviez choisir Application Web. Vous pouvez avoir un site Web faisant référence à un projet de bibliothèque de classes contenant tout le code du site Web. Les applications Web ne sont qu'un moyen pratique de le faire.
CodeBehind
Cette rubrique est spécifique aux fichiers .aspx et .ascx. Cette rubrique est de moins en moins pertinente dans les nouvelles infrastructures d'application telles que ASP.NET MVC et les pages Web ASP.NET qui n'utilisent pas de fichiers codebehind.
En ayant tous les fichiers de code compilés dans un seul assemblage, y compris codebehind fichiers de pages .aspx et de contrôles .ascx, dans les applications Web, vous devez recréer à chaque petit changement et vous ne pouvez pas effectuer de modifications en direct. . Cela peut être très pénible pendant le développement, car vous devez continuer à reconstruire pour voir les modifications, tandis qu'avec les sites Web, les modifications sont détectées par le moteur d'exécution et les pages/contrôles sont automatiquement recompilés.
Avoir le runtime à gérer les assemblys codeownhind représente moins de travail, car vous n'avez pas à vous soucier de donner des noms uniques aux pages/contrôles, ni de les organiser en différents espaces de noms.
Je ne dis pas que le déploiement de fichiers de code est toujours une bonne idée (en particulier dans le cas de fichiers de code partagés), mais les fichiers code-behind ne doivent contenir que du code exécutant des tâches spécifiques à l'interface utilisateur, des gestionnaires d'événements de connexion, etc. Votre application doit être de manière à ce que le code important finisse toujours dans le dossier Bin. Si tel est le cas, le déploiement de fichiers codebehind ne doit pas être considéré comme dangereux.
Une autre limitation des applications Web est que vous ne pouvez utiliser que la langue du projet. Sur les sites Web, vous pouvez avoir certaines pages en C #, d'autres en VB, etc. Inutile de prendre en charge Visual Studio. C’est la beauté de l’extensibilité du fournisseur de construction.
De plus, dans les applications Web, les pages/contrôles ne détectent pas les erreurs car le compilateur ne compile que les classes codebehind, et non le code de balisage (dans MVC, vous pouvez résoudre ce problème à l'aide de l'option MvcBuildViews), qui est compilé à l'exécution.
Visual Studio
Les applications Web étant des projets Visual Studio, certaines fonctionnalités ne sont pas disponibles dans les sites Web. Par exemple, vous pouvez utiliser les événements de construction pour effectuer diverses tâches, par exemple. Minify et/ou combiner des fichiers Javascript.
Une autre fonctionnalité intéressante de Visual Studio 2010 est transformation Web.config . Ceci n’est pas non plus disponible sur les sites Web. Fonctionne maintenant avec les sites Web dans VS 2013.
La création d'une application Web est plus rapide que la création d'un site Web, spécialement pour les grands sites. Cela est principalement dû au fait que les applications Web ne compilent pas le code de balisage. Dans MVC, si vous définissez MvcBuildViews sur true, le code de balisage est compilé et vous obtenez la détection des erreurs, ce qui est très utile. L'inconvénient est que chaque fois que vous créez la solution, le site complet est créé, ce qui peut être lent et inefficace, en particulier si vous ne modifiez pas le site. Je me trouve à activer/désactiver MvcBuildViews (ce qui nécessite un déchargement du projet). D'autre part, avec les sites Web, vous pouvez choisir de créer ou non le site dans le cadre de la solution. Si vous ne le souhaitez pas, la construction de la solution est très rapide. Vous pouvez toujours cliquer sur le nœud du site Web et sélectionner Construire, si vous avez apporté des modifications.
Dans un projet d’application Web MVC, vous disposez de commandes et de boîtes de dialogue supplémentaires pour les tâches courantes, telles que "Ajouter une vue", "Aller à la vue", "Ajouter un contrôleur", etc. Elles ne sont pas disponibles sur un site Web MVC.
Si vous utilisez IIS Express en tant que serveur de développement, vous pouvez ajouter des répertoires virtuels dans les sites Web. Cette option n'est pas disponible dans les applications Web.
La restauration de package NuGet ne fonctionne pas sur les sites Web, vous devez installer manuellement les packages répertoriés dans packages.config. La restauration de paquet fonctionne maintenant avec les sites Web à partir de NuGet 2.7
Site Web = utiliser lorsque le site Web est créé par des graphistes et que les programmeurs n'éditent qu'une ou deux pages
Application Web = à utiliser lorsque l'application est créée par des programmeurs et que les graphistes n'éditent qu'une ou deux images/paginées.
Les sites Web peuvent être travaillés avec n'importe quel outil HTML sans avoir à créer de studio de développement, car les fichiers de projet n'ont pas besoin d'être mis à jour, etc.
(Certaines erreurs de codage se produisent dans les applications Web au moment de la compilation et ne sont pas détectées dans les sites Web avant l'exécution.)
Attention:J'ai écrit cette réponse il y a plusieurs années et je n'ai pas utilisé Asp.net depuis. Je m'attends à ce que les choses bougent maintenant.
Sauf si vous avez un besoin spécifique pour un projet compilé de manière dynamique, n'utilisez pas de projet de site Web .
Pourquoi? Parce que le projet de site Web vous mènera au mur lorsque vous essayez de modifier ou de comprendre votre projet. Les fonctionnalités de recherche de frappe statique (par exemple, les utilisations de la recherche, le refactor) dans Visual Studio prendront une durée indéterminée pour tout projet de taille raisonnable. Pour plus d'informations, voir la question relative au dépassement de capacité "Recherche lente de toutes les références" dans Visual Studio.
Je ne vois vraiment pas pourquoi ils ont abandonné les applications Web dans Visual Studio 2005 pour le type de projet de site Web carbuncle source de douleur et de perte de cohérence.
Il existe un article dans MSDN qui décrit les différences:
Comparaison de projets de site Web et de projets d'application Web
BTW: il y a quelques questions similaires sur ce sujet, par exemple:
- Site Web par rapport à une application Web ASP.Net dans Visual Studio Remarque: a été supprimé, mais plus sous SO .
- site Web ou application Web in.ASP.NET
Cela peut sembler un peu évident, mais je pense que c'est quelque chose qui est mal compris parce que Visual Studio 2005 était uniquement livré avec le site Web à l'origine. Si votre projet concerne un site Web assez limité et ne comportant pas beaucoup de séparation logique ou physique, le site Web est correct. Cependant, s'il s'agit vraiment d'une application Web avec différents modules où de nombreux utilisateurs ajoutent et mettent à jour des données, il vaut mieux utiliser l'application Web.
Le principal avantage du modèle de site Web est que tout ce qui se trouve dans la section app_code est compilé de manière dynamique. Vous pouvez effectuer des mises à jour du fichier C # sans redéployer complètement. Cependant, cela vient à un grand sacrifice. Beaucoup de choses se passent sous des couvertures difficiles à contrôler. Les espaces de noms sont difficiles à contrôler et l'utilisation spécifique de DLL sort de la fenêtre par défaut pour tout élément situé sous app_code puisque tout est compilé de manière dynamique.
Le modèle d'application Web n'a pas de compilation dynamique, mais vous pouvez contrôler les éléments que j'ai mentionnés.
Si vous effectuez un développement à plusieurs niveaux, je vous recommande vivement le modèle d'application Web. Si vous utilisez un site Web limité ou une implémentation rapide et sale, le modèle de site Web peut présenter des avantages.
Une analyse plus détaillée peut être trouvée dans:
Extrait du livre 70-515 de la trousse de formation auto-rythmée des SCTM:
Avec application web (projet),
- Vous pouvez créer une application MVC.
- Visual Studio stocke la liste des fichiers dans un fichier de projet (.csproj ou .vbproj) plutôt que de s'appuyer sur la structure de dossiers.
- Vous ne pouvez pas mélanger Visual Basic et C #.
- Vous ne pouvez pas modifier le code sans arrêter une session de débogage.
- Vous pouvez établir des dépendances entre plusieurs projets Web.
- Vous devez compiler l'application avant le déploiement, ce qui vous empêche de tester une page si une autre page ne compile pas.
- Vous n'êtes pas obligé de stocker le code source sur le serveur.
- Vous pouvez contrôler le nom et la version de l’assemblage.
- Vous ne pouvez pas éditer des fichiers individuels après le déploiement sans recompiler.
CompilationPremièrement, il y a une différence dans la compilation. Le site Web n'est pas précompilé sur le serveur, il est compilé sur fichier. Cela peut constituer un avantage, car si vous souhaitez modifier quelque chose sur votre site Web, vous pouvez simplement télécharger un fichier spécifique à partir du serveur, le modifier et le transférer à nouveau sur le serveur. Tout se passera bien. Dans Web Application, vous ne pouvez pas le faire car tout est pré-compilé et vous vous retrouvez avec une seule DLL. Lorsque vous modifiez quelque chose dans un fichier de votre projet, vous devez tout recompiler à nouveau. Donc, si vous souhaitez avoir la possibilité de modifier certains fichiers sur le serveur, le site Web est la meilleure solution pour vous. Il permet également à de nombreux développeurs de travailler sur un seul site Web. D'un autre côté, si vous ne voulez pas que votre code soit disponible sur le serveur, vous devriez plutôt choisir Web Application. Cette option est également préférable pour les tests unitaires car un fichier DLL est créé après la publication de votre site Web.
Project structure Il existe également une différence dans la structure du projet. Dans l'application Web, vous avez un fichier de projet, comme vous l'aviez dans une application normale. Sur le site Web, il n’existe aucun fichier de projet traditionnel, vous n’avez qu’un fichier de solution. Toutes les références et les paramètres sont stockés dans le fichier web.config. @Page directive Il existe un attribut différent dans la directive @Page pour le fichier contenant la classe associée à cette page. Dans l'application Web, c'est "CodeBehind" standard, dans le site Web, vous utilisez "CodeFile". Vous pouvez le voir dans les exemples ci-dessous:
Application Web:
_<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"
Inherits="WebApplication._Default" %>
_Site Web:
_<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %>
_Espaces de noms - Dans l'exemple ci-dessus, vous pouvez également voir une autre différence: la manière dont les espaces de noms sont créés. Dans l’application de noms Web, l’espace est simplement un nom du projet. Dans Website, il existe un espace de noms par défaut ASP pour les pages compilées dynamiquement.
Modifier et continuer - Dans l'application Web, l'option Modifier et continuer est disponible (pour l'activer, vous devez aller dans le menu Outils, cliquer sur Options puis trouver Éditer et continuer dans le débogage). Cette fonctionnalité ne fonctionne pas dans le site Web.ASP.NET MVCIsi vous souhaitez développer des applications Web à l'aide de
ASP.NET MVC (Contrôleur de vue modèle), la meilleure option par défaut est l'application Web. Bien qu'il soit possible d'utiliser MVC dans un site Web, cela n'est pas recommandé.
Résumé - La principale différence entre une application Web ASP.NET et un site Web réside dans la compilation. Donc, si vous travaillez sur un projet plus important pouvant être modifié par quelques personnes, il est préférable d'utiliser Site Web. Mais si vous faites un projet plus petit, vous pouvez également utiliser Web Application.
Cela dépend de ce que vous développez.
Le contenu d'un site Web orienté contenu change fréquemment et un site Web est préférable pour cela.
Une application a tendance à avoir ses données stockées dans une base de données et ses pages et le code changent rarement. Dans ce cas, il est préférable d'avoir une application Web dans laquelle le déploiement des assemblys est beaucoup plus contrôlé et prend mieux en charge les tests unitaires.
L'une des principales différences est que les sites Web se compilent de manière dynamique et créent des assemblys à la volée. Les applications Web sont compilées dans une grande assemblée.
La distinction entre les deux a été supprimée dans Visual Studio 2008.
Oui, les applications Web sont bien meilleures que les sites Web, car elles nous donnent la liberté:
Pour avoir plusieurs projets sous un même parapluie et établir des dépendances de projet entre. Par exemple. pour PCS, nous pouvons avoir les applications suivantes dans l'application Web:
- Portails Web
- Notification Controller (pour l'envoi d'email)
- Couche métier
- Couche d'accès aux données
- Gestionnaire d'exceptions
- Utilitaire serveur
- Services WCF (communs à toutes les plateformes)
- Élément de liste
Pour exécuter des tests unitaires sur le code contenu dans les fichiers de classe associés aux pages ASP.NET
- Pour faire référence aux classes associées à des pages et à des contrôles utilisateur issus de classes autonomes
- Pour créer un seul assemblage pour l'ensemble du site
- Contrôle sur le nom de l'assembly et le numéro de version généré pour le site
- Pour éviter de mettre du code source sur un serveur de production. (Vous pouvez éviter de déployer du code source sur le serveur IIS. Dans certains scénarios, tels que les environnements d'hébergement partagé, vous pouvez craindre un accès non autorisé au code source sur le serveur IIS. (( Pour un projet de site Web, vous pouvez éviter ce risque en compilant à l'avance sur un ordinateur de développement et en déployant les assemblys générés à la place du code source. Cependant, dans ce cas, vous perdez certains des avantages des mises à jour de site faciles.)
- Problème de performance avec le site Web (la première demande sur le site Web peut nécessiter sa compilation, ce qui peut entraîner un délai. Et si le site Web est exécuté sur un serveur IIS dont la mémoire est insuffisante, l'inclusion de l'ensemble du site dans un seul assemblage pourrait utiliser plus de mémoire que ce qui serait nécessaire pour plusieurs assemblys.)
Les applications sont généralement compilées avant le déploiement, où le site Web utilise le répertoire app_code. Lorsque quelque chose change dans le dossier du code de l'application, le serveur recompilera le code. Cela signifie que vous pouvez ajouter/changer le code avec un site Web à la volée.
L'avantage d'une application est qu'il n'y a pas de nouvelle compilation et que les temps de démarrage initiaux seront plus rapides.
Je vous recommande de regarder la vidéo projets d'application Web et projets de déploiement Web sur le site Web ASP.NET, ce qui explique la différence détail, c’était très utile pour moi.
Soit dit en passant, ne vous perdez pas dans le titre. Une grande partie de la vidéo explique la différence entre les projets de site Web et les projets d’application Web et explique pourquoi Microsoft a réintroduit les projets d’application Web dans Visual studio 2005 (comme vous le savez probablement déjà livré à l'origine avec des projets de site Web uniquement, des projets d'application Web ont été ajoutés à SP1). Une excellente vidéo que je recommande vivement à quiconque veut connaître la différence.
Un "site Web" a son code dans un répertoire App_Code spécial et il est compilé en plusieurs DLL (assemblys) au moment de l'exécution. Une "application Web" est précompilée dans une seule DLL.
Cela dépend toujours de l'exigence de votre client. ASP.NET comprend uniquement les fonctionnalités flexibles dont l'utilisateur a besoin pour assurer la sécurité et faciliter la maintenance de votre application.
Vous pouvez considérer application Web comme un fichier binaire qui s'exécute dans le cadre ASP.NET. Et Sites Web en tant que page Web statique sur laquelle vous pouvez consulter et déployer facilement le code source.
Mais ce qui est bon, c’est l’avantage et les inconvénients de ces deux technologies ASP.NET.
Website et Project >> website sont deux méthodes différentes pour créer une application ASP.NET à l'aide de Visual Studio. L'un est sans projet et l'autre est l'environnement de projet. Les différences sont comme
- Le fichier de solution est stocké dans le même répertoire que le répertoire racine dans l'environnement de projet.
- Nécessité de supprimer les fichiers de solution et de projet avant le déploiement dans un environnement de projet.
- Le répertoire racine complet est déployé dans un environnement sans projet.
il n’ya pas beaucoup de différence fondamentale entre l’une ou l’autre approche. Mais si vous créez un site Web qui prendra plus de temps, optez pour l'environnement de projet.
modèle de projet d'application Web
- Fournit la même sémantique de projet Web que les projets Web Visual Studio .NET. Possède un fichier de projet (structure basée sur les fichiers de projet). Modèle de construction: tout le code du projet est compilé dans un seul assemblage. Prend en charge IIS et le serveur de développement ASP.NET intégré. Prend en charge toutes les fonctionnalités de Visual Studio 2005 (refactoring, génériques, etc.) et d’ASP.NET (pages maîtres, adhésion et connexion, navigation sur le site, thèmes, etc.). L'utilisation des extensions serveur FrontPage (FPSE) n'est plus une exigence.
modèle de projet de site Web
- Aucun fichier de projet (basé sur le système de fichiers).
- Nouveau modèle de compilation.
- Compilation dynamique et travail sur les pages sans créer un site entier sur chaque affichage de page.
- Prend en charge IIS et le serveur de développement ASP.NET intégré.
- Chaque page a sa propre assemblée.
- Modèle de code différent.
Sites Web - Aucun fichier de solution ne sera créé. Si nous voulons créer des sites Web, pas besoin de Visual Studio.
Application Web - Un fichier de solution sera créé. Si nous voulons créer une application Web, nous avons besoin du Visual Studio. Il créera un seul fichier .dll dans le dossier bin.
Les applications Web nécessitent plus de mémoire, probablement parce que vous n'avez pas d'autre choix que de les compiler en un seul assemblage. Je viens de convertir un site volumineux en une application Web et des problèmes d’épuisement de la mémoire, à la compilation, avec le message d’erreur ci-dessous:
Unexpected error writing metadata to file '' --
Not enough storage is available to complete this operation.
erreur, et au moment de l'exécution avec ce message d'erreur comme ci-dessous:
Exception information:
Exception type: HttpException
Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()
Ma recommandation pour la conversion de sites volumineux sur du matériel hérité contraint de mémoire est de choisir de revenir au modèle de site Web. Même après un premier succès, le problème pourrait se poser plus tard.
Certainement une application Web, un seul fichier DLL et facile à gérer. Mais un site Web est plus flexible. vous pouvez modifier le fichier aspx lors de vos déplacements.
Site Internet : Il génère automatiquement le dossier app_code et si vous le publiez sur le serveur, après quoi, si vous apportez des modifications à un fichier ou à une page en particulier, vous n'avez pas à compiler tous les fichiers.
Application Web Il génère automatiquement un fichier de solutions que le site Web ne génère pas et si vous modifiez dans un fichier, vous devez compiler le projet complet pour refléter ses modifications.
Dans une application Web, vous pouvez créer les couches de la fonctionnalité de votre projet et créer des interdépendances en les divisant en plusieurs projets, mais vous ne pouvez jamais le faire sur un site Web.
Dans les projets d'application Web, Visual Studio a besoin de fichiers .designer supplémentaires pour les pages et les contrôles utilisateur. Les projets de site Web ne nécessitent pas cette surcharge. Le balisage lui-même est interprété comme la conception.
Ici, l'application Web de support est un exemple de site Web. Site Web et application Web peuvent être dynamiques/statiques, cela dépend des besoins. Voici un exemple pour comprendre le fonctionnement du site Web et de l'application Web.
Pour résumer certaines des réponses ci-dessus:
Flexibilité , pouvez-vous modifier en direct une page Web?
Site Web : Possible. Pro: avantages à court terme. Contre: risque à long terme de chaos de projet.
Web App : Con: impossible. Modifiez une page, archivez les modifications dans le contrôle de source, puis construisez et déployez l'intégralité du site. Pro: maintenir un projet de qualité.
Problèmes de développement
Site Web : structure de projet simple sans fichier .csproj. Deux pages .aspx peuvent porter le même nom de classe sans conflit. Nom de répertoire de projet aléatoire entraînant des erreurs de construction telles que pourquoi le framework .net est en conflit avec son propre fichier généré et pourquoi le framework .net est en conflit avec son propre fichier généré . Pro: simple (simpliste). Con: erratique.
Web App : structure de projet similaire au projet WebForms, avec un fichier .csproj. Les noms de classe des pages asp doivent être uniques. Pro: simple (intelligent). Contre: aucun, car une application web est toujours simple.