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 je peux créer 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 selon la version de Visual Studio que j'utilise?


Answers



Site Internet:

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 n'est peut-être pas encore compilé en code. Un autre problème peut être dans la publication.

Si Visual Studio n'est pas dit de réutiliser les mêmes noms en permanence, il trouvera de nouveaux noms pour les fichiers DLL générés par les pages tout le temps. Cela peut conduire à avoir plusieurs copies proches de fichiers DLL contenant le même nom de classe, ce qui générera beaucoup d'erreurs. Le projet de site Web a été introduit avec Visual Studio 2005, mais il s'est avéré ne pas être extrêmement populaire.

Application Web:

Le projet d' application Web a été créé en tant que complément et existe maintenant dans le cadre du SP 1 pour Visual Studio 2005. Les principales différences sont que le projet d'application Web a été conçu pour fonctionner de manière similaire aux projets Web fournis avec Visual Studio 2003. Il compilez l'application dans un seul fichier DLL au moment de la construction. Afin de mettre à jour le projet, il doit être recompilé et le fichier DLL publié pour que les modifications se produisent.

Une autre fonctionnalité intéressante du projet Application Web est qu'il est beaucoup plus facile d'exclure des fichiers de la vue du projet. Dans le projet Site Web, chaque fichier que vous excluez est renommé avec un mot clé d'exclusion dans le nom de fichier. Dans le projet d'application Web, le projet ne fait que suivre les fichiers à inclure / exclure de la vue du projet sans les renommer, ce qui rend les choses beaucoup plus ordonnées.

Référence

L'article ASP.NET 2.0 - Site Web par rapport à l'application Web explique également pourquoi utiliser l'un et pas l'autre. Voici un extrait de celui-ci:

  • Vous devez migrer de grandes applications Visual Studio .NET 2003 vers VS 2005? utilisez le projet d'application Web.
  • Vous souhaitez ouvrir et modifier un répertoire en tant que projet Web sans créer de fichier de projet? utiliser le projet de site Web.
  • Vous devez ajouter des étapes de pré-construction et de post-construction lors de la compilation? utiliser le projet d'application Web.
  • Vous devez créer une application Web en utilisant plusieurs projets Web? utiliser le projet d'application Web.
  • Vous voulez générer un assemblage pour chaque page? utiliser le projet de site Web.
  • Vous préférez la compilation dynamique et le travail sur des pages sans construire le site entier sur chaque page vue? utiliser le projet de site Web.
  • Vous préférez un modèle de code à une seule page au modèle code-behind? utiliser le projet de site Web.

Les projets d'application Web par rapport aux projets de site Web (MSDN) expliquent les différences entre les projets de sites Web et d'applications Web. En outre, il traite de la configuration à effectuer dans Visual Studio.




Le 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. Il n'y a rien dans un site Web qui vous lie à Visual Studio (il n'y a pas de fichier de projet). La génération de code et la compilation de pages Web (telles que .aspx, .ascx, .master) sont effectuées dynamiquement au moment de l'exécution , et les modifications apportées à ces fichiers sont détectées par le framework et automatiquement recompilées. Vous pouvez placer 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'assembly dans le dossier Bin.

Application Web est un projet Visual Studio spécial. 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 vous le feriez dans la bibliothèque de classes. Étant donné que les applications Web contiennent des fichiers qui ne sont pas destinés à être déployés, tels que les fichiers de projet et de code, il existe une commande Publier dans Visual Studio pour générer un site Web à un emplacement spécifié.

App_Code vs Bin

Le déploiement de fichiers de code partagé est généralement une mauvaise idée, mais cela ne signifie pas que vous devez choisir Application Web. Vous pouvez avoir un site Web qui référence un projet de bibliothèque de classes qui contient tout le code pour le site Web. Les applications Web sont simplement un moyen pratique de le faire.

CodeBehind

Cette rubrique est spécifique aux fichiers .aspx et .ascx. Cette rubrique est de plus en plus pertinente dans les nouveaux cadres d'application tels que ASP.NET MVC et les pages Web ASP.NET qui n'utilisent pas les fichiers codebehind.

En compilant tous les fichiers de code en un seul assemblage, y compris les fichiers codebehind des pages .aspx et des contrôles .ascx, dans les applications Web, vous devez recréer chaque petite modification 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 changements, 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.

Le fait que le runtime gère les assemblages codebehind est moins de travail pour vous, car vous n'avez pas besoin de vous soucier de donner des noms uniques aux pages / contrôles, ou de les organiser dans des espaces de noms différents.

Je ne dis pas que le déploiement de fichiers de code est toujours une bonne idée (spécialement dans le cas de fichiers de code partagés), mais les fichiers codebehind ne doivent contenir que du code qui exécute des tâches spécifiques, des gestionnaires d'événements, etc. en couches afin que le code important finisse toujours dans le dossier Bin. Si tel est le cas, le déploiement de fichiers codebehind ne devrait pas être considéré comme dangereux.

Une autre limitation des applications Web est que vous ne pouvez utiliser que la langue du projet. Dans les sites Web, vous pouvez avoir quelques pages en C #, certaines en VB, etc. Pas besoin de support Visual Studio spécial. C'est la beauté de l'extensibilité du fournisseur de build.

En outre, dans les applications Web, la détection des erreurs ne se fait pas dans les pages / contrôles, car le compilateur compile uniquement vos classes codebehind et non le code de balisage (dans MVC, vous pouvez le corriger à l'aide de l'option MvcBuildViews).

Visual Studio

Étant donné que les applications Web sont des projets Visual Studio, certaines fonctionnalités ne sont pas disponibles sur les sites Web. Par exemple, vous pouvez utiliser des événements de construction pour effectuer une variété de tâches, par exemple réduire et / ou combiner des fichiers Javascript.

Une autre fonctionnalité intéressante introduite dans Visual Studio 2010 est la transformation Web.config . Ceci n'est pas non plus disponible sur les sites Web. Travaille maintenant avec les sites Web dans VS 2013.

Construire une application Web est plus rapide que la construction d'un site Web, spécialement pour les grands sites. Ceci est principalement dû au fait que les applications Web ne compilent pas le code de balisage. Dans MVC si vous définissez MvcBuildViews à true, il compile le code de balisage et vous obtenez la détection d'erreur, ce qui est très utile. L'inconvénient est que chaque fois que vous construisez la solution, il construit le site complet, ce qui peut être lent et inefficace, surtout si vous ne modifiez pas le site. Je me retrouve à activer et désactiver MvcBuildViews (ce qui nécessite un déchargement de projet). D'un autre côté, avec les sites Web, vous pouvez choisir si vous voulez construire le site dans le cadre de la solution ou non. Si vous choisissez de ne pas le faire, la création de la solution est très rapide et vous pouvez toujours cliquer sur le nœud Site Web et sélectionner Générer, si vous avez apporté des modifications.

Dans un projet 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. Ces sites ne sont pas disponibles sur un site Web MVC.

Si vous utilisez IIS Express comme 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.

NuGet Package Restore ne fonctionne pas sur les sites Web, vous devez installer manuellement les paquets listés sur packages.config La restauration de package 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 / pages paginées.

Les sites Web peuvent être travaillés en utilisant des outils HTML sans avoir de studio de développement, car les fichiers de projet n'ont pas besoin d'être mis à jour, etc. Les applications Web sont meilleures quand l'équipe utilise principalement studio de développement et qu'il y a beaucoup de code.

(Certaines erreurs de codage se trouvent dans les applications Web au moment de la compilation et ne se trouvent pas dans les sites Web avant l'exécution.)

Attention: j'ai écrit cette réponse il y a de nombreuses années et je n'ai plus utilisé Asp.net depuis. Je m'attends à ce que les choses aient évolué.




À moins que vous n'ayez un besoin spécifique pour un projet compilé dynamiquement, n'utilisez pas un projet de site Web .

Pourquoi? Parce que le projet de site Web vous conduira vers le haut du mur en essayant de changer ou de comprendre votre projet. Les fonctionnalités de recherche de typage statique (par exemple, find uses, refactor) dans Visual Studio prennent toutes une éternité sur tout projet de taille raisonnable. Pour plus d'informations, consultez la question de dépassement de pile lente «Rechercher toutes les références» dans Visual Studio .

Je ne vois vraiment pas pourquoi ils ont abandonné des applications Web dans Visual Studio 2005 pour le type de projet de site Web de carbuncle induisant la douleur, la santé mentale et la productivité.







Cela peut sembler un peu évident, mais je pense que c'est quelque chose qui est mal compris parce que Visual Studio 2005 est seulement livré avec le site Web à l'origine. Si votre projet porte sur un site Web assez limité et qui ne comporte pas beaucoup de séparation logique ou physique, le site Web est parfait. 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 plus grand pro du modèle de site Web est que tout ce qui se trouve dans la section app_code est compilé dynamiquement. Vous pouvez effectuer des mises à jour de fichiers C # sans redéploiement complet. 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 la DLL sort de la fenêtre par défaut pour tout ce qui se trouve sous app_code car tout est compilé dynamiquement.

Le modèle d'application Web n'a pas de compilation dynamique, mais vous prenez le contrôle des choses que j'ai mentionnées.

Si vous faites du développement en n-tier, je recommande fortement le modèle d'application web. Si vous faites un site Web limité ou une mise en œuvre rapide et sale, le modèle de site Web peut avoir des avantages.

Une analyse plus détaillée peut être trouvée dans:




De l'examen MCTS auto-entraîné kit de formation examen 70-515:

Avec une application web (projet),

  1. Vous pouvez créer une application MVC.
  2. 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.
  3. Vous ne pouvez pas mélanger Visual Basic et C #.
  4. Vous ne pouvez pas modifier le code sans arrêter une session de débogage.
  5. Vous pouvez établir des dépendances entre plusieurs projets Web.
  6. 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.
  7. Vous n'avez pas besoin de stocker le code source sur le serveur.
  8. Vous pouvez contrôler le nom et la version de l'assembly.
  9. Vous ne pouvez pas modifier des fichiers individuels après le déploiement sans recompilation.



Cela dépend de ce que vous développez.

Un site Web axé sur le contenu aura son contenu change fréquemment et un site Web est meilleur pour cela.

Une application a tendance à stocker ses données dans une base de données et ses pages et codes changent rarement. Dans ce cas, il est préférable d'avoir une application Web où le déploiement des assemblages est beaucoup plus contrôlé et qui supporte mieux les tests unitaires.




Compilation Premièrement, il y a une différence dans la compilation. Site Web n'est pas pré-compilé sur le serveur, il est compilé sur le fichier. Cela peut être un avantage car lorsque vous voulez changer quelque chose dans votre site Web, vous pouvez simplement télécharger un fichier spécifique du serveur, le changer et télécharger ce fichier sur le serveur et tout fonctionnerait bien. Dans Web Application, vous ne pouvez pas faire cela parce que everthing 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 re-compiler à nouveau. Donc, si vous souhaitez avoir la possibilité de modifier certains fichiers sur le serveur, le site Web est une meilleure solution pour vous. Il permet également à de nombreux développeurs de travailler sur un site Web. D'un autre côté, si vous ne voulez pas que votre code soit disponible sur le serveur, choisissez plutôt Web Application. Cette option est également préférable pour les tests unitaires en raison de la création d'un fichier DLL après la publication de votre site Web.

Project structure Il existe également une différence dans la structure du projet. Dans Application Web, vous avez un fichier de projet comme vous l'avez fait dans une application normale. Dans le site Web il n'y a pas de fichier de projet traditionnel, tout ce que vous avez est 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 qui contient la classe associée à cette page. Dans Web Application, il est standard "CodeBehind", dans le site Web, vous utilisez "CodeFile". Vous pouvez le voir dans les exemples ci-dessous:

Web Application:

<%@ Page Language="C#" AutoEventWireup="true" CodeBehind="Default.aspx.cs"  
Inherits="WebApplication._Default" %>  

Site Internet:

<%@ Page Language="C#" AutoEventWireup="true" CodeFile="Default.aspx.cs" Inherits="_Default" %> 

Espaces de nommage - Dans l'exemple ci-dessus, vous pouvez également voir une autre différence - comment les espaces de noms sont créés. Dans l'espace de noms d'application Web est simplement un nom du projet. Dans le site Web, il existe un espace de noms ASP par défaut pour les pages compilées dynamiquement.

Modifier et continuer - Dans l'application Web Modifier et continuer l'option est disponible (pour l'activer, vous devez aller dans le menu Outils, cliquez sur Options, puis sur Modifier et continuer dans le débogage). Cette fonctionnalité ne fonctionne pas dans Web Site.ASP.NET MVCIf que vous souhaitez développer des applications Web en utilisant

ASP.NET MVC (Model View Controller) la meilleure et l'option par défaut est l'application Web. Bien qu'il soit possible d'utiliser MVC dans un site Web, ce n'est pas recommandé.

Résumé - La différence la plus importante entre l'application Web ASP.NET et le site Web est la compilation. Donc, si vous travaillez sur un projet plus important où quelques personnes peuvent le modifier, il est préférable d'utiliser le site Web. Mais si vous faites un projet plus petit, vous pouvez également utiliser l'application Web.




L'une des principales différences est que les sites Web se compilent dynamiquement et créent des assemblages à la volée. Les applications Web se compilent en un grand assemblage.

La distinction entre les deux a été supprimée dans Visual Studio 2008.




Oui, l'application web est bien meilleure que les sites web, car les applications Web nous donnent la liberté:

  1. Pour avoir plusieurs projets sous un même parapluie et établir des dépendances de projet entre. Par exemple, pour PCS, nous pouvons avoir des applications Web

    • Portails Web
    • Notification Controller (pour l'envoi de courrier électronique)
    • Couche métier
    • Couche d'accès aux données
    • Gestionnaire d'exceptions
    • Utilitaire de serveur
    • Services WCF (communs pour toutes les plateformes)
    • Élément de liste
  2. Pour exécuter des tests unitaires sur le code contenu dans les fichiers de classe associés aux pages ASP.NET

  3. Pour faire référence aux classes, celles-ci sont associées aux pages et aux contrôles utilisateur des classes autonomes
  4. Pour créer un seul assembly pour l'ensemble du site
  5. Contrôle du nom de l'assembly et du numéro de version générés pour le site
  6. Pour éviter de placer le 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és, vous pouvez être préoccupé par l'accès non autorisé au code source sur le serveur IIS (pour un projet de site Web). pré-compiler sur un ordinateur de développement et déployer les assemblées générées au lieu du code source, mais dans ce cas, vous perdez certains avantages des mises à jour de site faciles.)
  7. Problème de performances avec le site Web (La première requête sur le site Web peut nécessiter la compilation du site, ce qui peut entraîner un retard et si le site Web est exécuté sur un serveur IIS dont la mémoire est insuffisante, y compris sur l'ensemble du site. assembly unique peut 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 utilise le répertoire app_code. Lorsque quelque chose change dans le dossier du code de l'application, le serveur recompile le code. Cela signifie que vous pouvez ajouter / modifier du code avec un site Web à la volée.

L'avantage d'une application est qu'il n'y a pas de recompilation et que les temps de démarrage initiaux seront donc plus rapides.




Je vous recommande de regarder la vidéo Web Application Projects & Web Deployment Projects sur le site ASP.NET qui explique la différence dans les moindres détails, cela m'a été très utile.

Au fait, ne vous méprenez pas sur le titre, une grande partie de la vidéo explique la différence entre les projets de sites Web et les applications Web et pourquoi Microsoft a réintroduit des projets d'application Web dans Visual Studio 2005 (comme vous le savez probablement déjà initialement livré avec uniquement des projets de sites Web, les projets d'application Web ont été ajoutés dans SP1). Une super vidéo que je recommande vivement à tous ceux qui veulent connaître la différence.




Un "site web" a son code dans un répertoire spécial App_Code et il est compilé en plusieurs DLL (assemblys) à l'exécution. Une "application web" est précompilée en une seule DLL.




Website et Project >> site sont deux méthodes différentes de création d'application ASP.NET en utilisant Visual Studio. L'un est sans projet et l'autre est l'environnement du projet. Les différences sont aussi

  1. Le fichier de solution est stocké dans le même répertoire que le répertoire racine dans l'environnement de projet.
  2. Nécessité de supprimer les fichiers de solution et de projet avant de les déployer dans un environnement de projet.
  3. Le répertoire racine complet est déployé dans un environnement sans projet.

il n'y a pas de différence fondamentale dans l'utilisation de 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. A un fichier de projet (structure basée sur des fichiers de projet). Construire le modèle - tout le code du projet est compilé en 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, membres et login, 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 des pages sans construire le site entier sur chaque page vue.
  • Prend en charge IIS et le serveur de développement ASP.NET intégré.
  • Chaque page a son propre assemblage.
  • Modèle de code Defferent.



Cela dépend toujours de l'exigence de votre client. ASP.NET ne comprend que des fonctionnalités flexibles dont l'utilisateur a besoin pour la sécurité et la maintenance facile de votre application.

Vous pouvez considérer une application Web comme un fichier binaire qui s'exécute dans l'infrastructure ASP.NET. Et les sites Web en tant que page Web statique que vous pouvez consulter et déployer facilement le code source.

Mais l'avantage et les inconvénients de ces deux technologies ASP.NET viennent de ce qui est bon.




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 le design.




WebSite: Il génère automatiquement le dossier app_code et si vous le publiez sur le serveur et après que si vous faites des changements dans un fichier ou une page particulière que vous n'avez pas à compiler tous les fichiers.

Application Web Génère automatiquement le fichier de solutions que le site Web ne génère pas et si vous modifiez dans un fichier que vous devez compiler le projet complet pour refléter ses changements.




Les applications Web nécessitent plus de mémoire, probablement parce que vous n'avez pas d'autre choix que de compiler en un seul assemblage. Je viens de convertir un grand site existant en une application web et j'ai des problèmes avec le manque de mémoire, à la fois lors de la compilation avec le

Unexpected error writing metadata to file '' -- 
Not enough storage is available to complete this operation. 

erreur et à l'exécution avec cette erreur:

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 plus importants sur du matériel hérité à mémoire limitée est de vous autoriser à revenir au modèle de site Web. Même après un succès initial, des problèmes peuvent surgir plus tard.




Dans une application Web, vous pouvez créer les couches de la fonctionnalité de votre projet et créer des interdépendances entre elles en la divisant en plusieurs projets, mais vous ne pouvez jamais le faire sur un site Web.




Définitivement application web, fichier DLL unique et facile à entretenir. Mais un site web est plus flexible; vous pouvez éditer le fichier aspx en déplacement.




Ici, Web Supportive Application est un exemple de site Web. Le site Web et l'application Web peuvent tous les deux être dynamiques / statiques selon leurs besoins, voici un exemple pour comprendre le fonctionnement du site Web et de l'application Web.




Sites Web - Aucun fichier de solution ne sera créé. Si nous voulons créer des sites Web pas besoin de studio visuel.

Application Web - Un fichier de solution sera créé. Si nous voulons créer une application web devrait avoir besoin du studio visuel. Il créera un seul fichier .dll dans le dossier bin.