ASP.NET-Website oder ASP.NET-Webanwendung?

Wenn ich ein neues ASP.NET-Projekt in Visual Studio starte, kann ich eine ASP.NET-Webanwendung oder eine ASP.NET-Website erstellen.

Was ist der Unterschied zwischen der ASP.NET-Webanwendung und der ASP.NET-Website? Warum sollte ich einen anderen vorziehen?

Unterscheidet sich die Antwort je nach der von mir verwendeten Version von Visual Studio?

Webseite:

Das Website- Projekt wird im laufenden Betrieb kompiliert. Sie haben am Ende viel mehr DLL-Dateien, was schmerzhaft sein kann. Es gibt auch Probleme, wenn Sie Seiten oder Steuerelemente in einem Verzeichnis haben, die auf Seiten und Steuerelemente in einem anderen Verzeichnis verweisen müssen, da das andere Verzeichnis möglicherweise noch nicht in den Code kompiliert wurde. Ein weiteres Problem kann beim Veröffentlichen sein.

Wenn Visual Studio nicht angewiesen wird, dieselben Namen ständig wiederzuverwenden, werden ständig neue Namen für die DLL-Dateien angezeigt, die von Seiten generiert werden. Dies kann dazu führen, dass mehrere nahe Kopien von DLL-Dateien mit demselben Klassennamen vorhanden sind, was zu zahlreichen Fehlern führt. Das Website-Projekt wurde mit Visual Studio 2005 eingeführt, hat sich jedoch als nicht beliebt erwiesen.

Internetanwendung:

Das Webanwendungsprojekt wurde als Add-In erstellt und ist jetzt als Teil von SP 1 für Visual Studio 2005 vorhanden. Die Hauptunterschiede bestehen darin, dass das Webanwendungsprojekt so konzipiert wurde, dass es ähnlich wie die mit Visual Studio 2003 gelieferten Webprojekte funktioniert Kompilieren Sie die Anwendung zur Erstellungszeit in eine einzelne DLL-Datei. Um das Projekt zu aktualisieren, muss es neu kompiliert und die DLL-Datei veröffentlicht werden, damit Änderungen vorgenommen werden können.

Eine weitere nette Funktion des Webanwendungsprojekts ist, dass es viel einfacher ist, Dateien aus der Projektansicht auszuschließen. Im Website-Projekt wird jede von Ihnen ausgeschlossene Datei mit einem ausgeschlossenen Schlüsselwort im Dateinamen umbenannt. Im Webanwendungsprojekt verfolgt das Projekt nur, welche Dateien in die Projektansicht aufgenommen oder aus dieser ausgeschlossen werden sollen, ohne sie umzubenennen, was die Dinge viel aufgeräumter macht.

Referenz

Der Artikel ASP.NET 2.0 - Website gegen Webanwendungsprojekt gibt auch Gründe an, warum das eine und nicht das andere verwendet werden soll. Hier ist ein Auszug davon:

• Sie müssen große Visual Studio .NET 2003-Anwendungen auf VS 2005 migrieren? Verwenden Sie das Webanwendungsprojekt.
• Sie möchten ein Verzeichnis als Webprojekt öffnen und bearbeiten, ohne eine Projektdatei zu erstellen? Verwenden Sie das Website-Projekt.
• Sie müssen während der Kompilierung Schritte vor und nach dem Erstellen hinzufügen? Verwenden Sie das Webanwendungsprojekt.
• Sie müssen eine Webanwendung mit mehreren Webprojekten erstellen? Verwenden Sie das Webanwendungsprojekt.
• Sie möchten für jede Seite eine Assembly generieren? Verwenden Sie das Website-Projekt.
• Sie bevorzugen die dynamische Kompilierung und das Bearbeiten von Seiten, ohne auf jeder Seitenansicht die gesamte Site zu erstellen? Verwenden Sie das Website-Projekt.
• Sie bevorzugen ein einseitiges Codemodell gegenüber einem Code-Behind-Modell? Verwenden Sie das Website-Projekt.

Webanwendungsprojekte im Vergleich zu Websiteprojekten (MSDN) erläutert die Unterschiede zwischen der Website und Webanwendungsprojekten. Außerdem wird die in Visual Studio durchzuführende Konfiguration erläutert.

Die Website stellen Sie auf einem ASP.NET-Webserver wie IIS bereit. Nur ein paar Dateien und Ordner. Eine Website enthält nichts, was Sie mit Visual Studio verbindet (es gibt keine Projektdatei). Die Codegenerierung und Kompilierung von Webseiten (wie .aspx, .ascx, .master) erfolgt dynamisch zur Laufzeit . Änderungen an diesen Dateien werden vom Framework erkannt und automatisch neu kompiliert. Sie können Code, den Sie zwischen Seiten teilen möchten, in den speziellen Ordner App_Code einfügen oder ihn vorkompilieren und die Assembly in den Ordner Bin legen.

Die Webanwendung ist ein spezielles Visual Studio-Projekt. Der Hauptunterschied zu Websites besteht darin, dass beim Erstellen des Projekts alle Codedateien in einer einzigen Assembly kompiliert werden, die im bin-Verzeichnis abgelegt wird. Sie stellen keine Codedateien auf dem Webserver bereit. Anstatt einen speziellen Ordner für gemeinsam genutzte Codedateien zu haben, können Sie diese wie in der Klassenbibliothek an einer beliebigen Stelle ablegen. Da Webanwendungen Dateien enthalten, die nicht bereitgestellt werden sollen, z. B. Projekt- und Codedateien, gibt es in Visual Studio den Befehl Veröffentlichen, mit dem eine Website an einem bestimmten Speicherort ausgegeben werden kann.

App_Code vs Bin

Das Bereitstellen von gemeinsam genutzten Codedateien ist im Allgemeinen eine schlechte Idee. Dies bedeutet jedoch nicht, dass Sie sich für eine Webanwendung entscheiden müssen. Sie können eine Website haben, die auf ein Klassenbibliotheksprojekt verweist, das den gesamten Code für die Website enthält. Webanwendungen sind nur eine bequeme Möglichkeit, dies zu tun.

CodeBehind

Dieses Thema ist spezifisch für ASPX- und ASCX-Dateien. Dieses Thema ist in neuen Anwendungsframeworks wie ASP.NET MVC und ASP.NET-Webseiten, die keine Codebehind-Dateien verwenden, immer weniger relevant.

Wenn Sie alle Codedateien in einer einzigen Assembly kompilieren lassen, einschließlich Codebehind- Dateien von ASPX-Seiten und ASCX-Steuerelementen, müssen Sie in Webanwendungen für jede kleine Änderung neu erstellen, und Sie können keine Live-Änderungen vornehmen. Dies kann während der Entwicklung sehr schmerzhaft sein, da Sie immer wieder neu erstellen müssen, um die Änderungen zu sehen, während bei Websites Änderungen von der Laufzeit erkannt werden und Seiten / Steuerelemente automatisch neu kompiliert werden.

Die Laufzeitverwaltung der Codebehind-Assemblys ist für Sie weniger aufwendig, da Sie sich nicht darum kümmern müssen, Seiten / Steuerelementen eindeutige Namen zu geben oder sie in verschiedenen Namespaces zu organisieren.

Ich sage nicht, dass das Bereitstellen von Codedateien immer eine gute Idee ist (insbesondere nicht im Fall von gemeinsam genutzten Codedateien), aber Codebehind-Dateien sollten nur Code enthalten, der UI-spezifische Aufgaben, Handler für Verbindungsereignisse usw. ausführt. Ihre Anwendung sollte es sein geschichtet, so dass wichtiger Code immer im Ordner Bin landet. Wenn dies der Fall ist, sollte die Bereitstellung von Codebehind-Dateien nicht als schädlich angesehen werden.

Eine weitere Einschränkung von Webanwendungen besteht darin, dass Sie nur die Sprache des Projekts verwenden können. Auf Websites können einige Seiten in C #, einige in VB usw. vorhanden sein. Es ist keine spezielle Visual Studio-Unterstützung erforderlich. Das ist das Schöne an der Erweiterbarkeit des Build-Anbieters.

Außerdem erhalten Sie in Webanwendungen keine Fehlererkennung in Seiten / Steuerelementen, da der Compiler nur Ihre Codebehind-Klassen und nicht den Markup-Code kompiliert (in MVC können Sie dies mit der Option MvcBuildViews beheben), die zur Laufzeit kompiliert wird.

Visual Studio

Da Webanwendungen Visual Studio-Projekte sind, erhalten Sie einige Funktionen, die auf Websites nicht verfügbar sind. Sie können beispielsweise Build-Ereignisse verwenden, um eine Vielzahl von Aufgaben auszuführen, z. B. das Minimieren und / oder Kombinieren von Javascript-Dateien.

Eine weitere nette Funktion, die in Visual Studio 2010 eingeführt wurde, ist die Web.config-Transformation .Dies ist auch auf Websites nicht verfügbar. Funktioniert jetzt mit Websites in VS 2013.

Das Erstellen einer Webanwendung ist schneller als das Erstellen einer Website, insbesondere für große Websites. Dies liegt hauptsächlich daran, dass Webanwendungen den Markup-Code nicht kompilieren. Wenn Sie in MVC MvcBuildViews auf true setzen, wird der Markup-Code kompiliert und Sie erhalten eine Fehlererkennung, was sehr nützlich ist. Der Nachteil ist, dass jedes Mal, wenn Sie die Lösung erstellen, die gesamte Site erstellt wird. Dies kann langsam und ineffizient sein, insbesondere wenn Sie die Site nicht bearbeiten. Ich stelle fest, dass ich MvcBuildViews ein- und ausschalte (was das Entladen eines Projekts erfordert). Auf der anderen Seite können Sie bei Websites auswählen, ob Sie die Website als Teil der Lösung erstellen möchten oder nicht. Wenn Sie dies nicht möchten, ist die Erstellung der Lösung sehr schnell. Sie können jederzeit auf den Knoten Website klicken und Erstellen auswählen, wenn Sie Änderungen vorgenommen haben.

In einem MVC-Webanwendungsprojekt verfügen Sie über zusätzliche Befehle und Dialogfelder für allgemeine Aufgaben wie "Ansicht hinzufügen", "Zur Ansicht wechseln", "Controller hinzufügen" usw. Diese sind auf einer MVC-Website nicht verfügbar.

Wenn Sie IIS Express als Entwicklungsserver verwenden, können Sie auf Websites virtuelle Verzeichnisse hinzufügen. Diese Option ist in Webanwendungen nicht verfügbar.

NuGet Package Restore funktioniert nicht auf Websites. Sie müssen die in packages.config aufgelisteten Pakete manuell installierenDie Paketwiederherstellung funktioniert jetzt mit Websites , auf denen NuGet 2.7 gestartet wird

Website = Verwendung, wenn die Website von Grafikdesignern erstellt wird und die Programmierer nur eine oder zwei Seiten bearbeiten

Webanwendung = Verwendung, wenn die Anwendung von Programmierern erstellt wird und die Grafikdesigner nur ein oder zwei Seiten / Bilder bearbeiten.

Websites können mit beliebigen HTML-Tools bearbeitet werden, ohne dass Entwicklerstudio erforderlich ist, da Projektdateien nicht aktualisiert werden müssen usw. Webanwendungen sind am besten geeignet, wenn das Team hauptsächlich Entwicklerstudio verwendet und ein hoher Code-Inhalt vorhanden ist.

(Einige Codierungsfehler werden zur Kompilierungszeit in Webanwendungen gefunden, die erst zur Laufzeit auf Websites gefunden werden.)

Warnung: Ich habe diese Antwort vor vielen Jahren geschrieben und Asp.net seitdem nicht mehr verwendet. Ich gehe davon aus, dass sich die Dinge jetzt weiterentwickelt haben.

Verwenden Sie kein Website-Projekt , es sei denn, Sie benötigen speziell ein dynamisch kompiliertes Projekt .

Warum? Weil ein Website-Projekt Sie an die Wand treibt, wenn Sie versuchen, Ihr Projekt zu ändern oder zu verstehen. Die statischen Suchfunktionen für die Eingabe (z. B. Verwendungszwecke finden, Refactor) in Visual Studio werden für jedes Projekt mit angemessener Größe ewig dauern. Weitere Informationen finden Sie in der Frage " Stapelüberlauf langsam" unter "Alle Referenzen suchen" in Visual Studio .

Ich kann wirklich nicht verstehen, warum sie Webanwendungen in Visual Studio 2005 für den Projekttyp Carbuncle-Website für schmerzverursachende, gesundheitsschädliche und produktive Carbuncle-Websites gelöscht haben.

In MSDN gibt es einen Artikel, der die Unterschiede beschreibt:

Vergleichen von Website-Projekten und Webanwendungsprojekten

Übrigens: Es gibt einige ähnliche Fragen zu diesem Thema, z.

• Website vs. ASP.Net-Webanwendung in Visual Studio Hinweis: wurde entfernt, nicht mehr auf SO
• Website oder Webanwendung in.ASP.NET

Dies mag etwas offensichtlich klingen, aber ich denke, es wird missverstanden, da Visual Studio 2005 ursprünglich nur mit der Website geliefert wurde. Wenn sich Ihr Projekt mit einer Website befasst, die ziemlich begrenzt ist und nicht viel logische oder physische Trennung aufweist, ist die Website in Ordnung. Wenn es sich jedoch wirklich um eine Webanwendung mit verschiedenen Modulen handelt, in denen viele Benutzer Daten hinzufügen und aktualisieren, ist die Webanwendung besser geeignet.

Der größte Vorteil des Website-Modells ist, dass alles in diesem app_codeAbschnitt dynamisch kompiliert wird. Sie können C # -Datei-Updates ohne vollständige erneute Bereitstellung durchführen. Dies bringt jedoch ein großes Opfer mit sich. Unter der Decke passieren viele Dinge, die schwer zu kontrollieren sind. Namespaces sind schwer zu kontrollieren und die spezifische DLL-Nutzung wird standardmäßig für alles unter dem Fenster ausgeblendet, app_codeda alles dynamisch kompiliert wird.

Das Webanwendungsmodell verfügt nicht über eine dynamische Kompilierung, aber Sie erhalten die Kontrolle über die von mir erwähnten Dinge.

Wenn Sie eine n-Tier-Entwicklung durchführen, empfehle ich das Webanwendungsmodell. Wenn Sie eine eingeschränkte Website oder eine schnelle und fehlerhafte Implementierung durchführen, kann das Website-Modell Vorteile haben.

Eine detailliertere Analyse finden Sie in:

• Webanwendungsprojekte und Webbereitstellungsprojekte finden Sie hier
• Website oder Webanwendung?

Aus dem MCTS Self-Paced Training Kit Prüfung 70-515 Buch:

Mit Webanwendung (Projekt),

1. Sie können eine MVC-Anwendung erstellen.
2. Visual Studio speichert die Liste der Dateien in einer Projektdatei (.csproj oder .vbproj), anstatt sich auf die Ordnerstruktur zu verlassen.
3. Sie können Visual Basic und C # nicht mischen.
4. Sie können Code nicht bearbeiten, ohne eine Debugging-Sitzung zu beenden.
5. Sie können Abhängigkeiten zwischen mehreren Webprojekten herstellen.
6. Sie müssen die Anwendung vor der Bereitstellung kompilieren, damit Sie eine Seite nicht testen können, wenn eine andere Seite nicht kompiliert werden kann.
7. Sie müssen den Quellcode nicht auf dem Server speichern.
8. Sie können den Namen und die Version der Baugruppe steuern.
9. Sie können einzelne Dateien nach der Bereitstellung nicht bearbeiten, ohne sie neu zu kompilieren.

Es hängt davon ab, was Sie entwickeln.

Bei einer inhaltsorientierten Website ändert sich der Inhalt häufig, und eine Website ist dafür besser geeignet.

In einer Anwendung werden die Daten in der Regel in einer Datenbank gespeichert, und die Seiten und der Code ändern sich selten. In diesem Fall ist es besser, eine Webanwendung zu haben, in der die Bereitstellung von Assemblys viel kontrollierter ist und Unit-Tests besser unterstützt.

Compilation Erstens gibt es einen Unterschied in der Zusammenstellung. Die Website ist nicht auf dem Server vorkompiliert, sondern in einer Datei. Dies kann von Vorteil sein, da Sie, wenn Sie etwas auf Ihrer Website ändern möchten, einfach eine bestimmte Datei vom Server herunterladen, ändern und diese Datei wieder auf den Server hochladen können. Alles würde gut funktionieren. In der Webanwendung können Sie dies nicht tun, da alles vorkompiliert ist und Sie nur eine DLL haben. Wenn Sie etwas in einer Datei Ihres Projekts ändern, müssen Sie alles erneut kompilieren. Wenn Sie also die Möglichkeit haben möchten, einige Dateien auf der Server-Website zu ändern, ist dies die bessere Lösung für Sie. Außerdem können viele Entwickler an einer Website arbeiten. Wenn Sie jedoch nicht möchten, dass Ihr Code auf dem Server verfügbar ist, sollten Sie lieber Webanwendung wählen.

Project structure Es gibt auch einen Unterschied in der Struktur des Projekts. In der Webanwendung haben Sie eine Projektdatei, wie Sie sie in einer normalen Anwendung hatten. Auf der Website gibt es keine herkömmliche Projektdatei. Sie haben lediglich eine Lösungsdatei. Alle Referenzen und Einstellungen werden in der Datei web.config gespeichert. @Page directive In der @ Page-Direktive gibt es ein anderes Attribut für die Datei, die die dieser Seite zugeordnete Klasse enthält. In der Webanwendung ist es Standard "CodeBehind", auf der Website verwenden Sie "CodeFile". Sie können dies in den folgenden Beispielen sehen:

Internetanwendung:

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

Webseite:

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

Namespaces - Im obigen Beispiel sehen Sie noch einen weiteren Unterschied - wie Namespaces erstellt werden. Im Webanwendungs-Namespace ist einfach ein Name des Projekts. In der Website gibt es einen Standard-Namespace-ASP für dynamisch kompilierte Seiten.

Bearbeiten und fortfahren - In der Webanwendung ist die Option Bearbeiten und fortfahren verfügbar (um sie zu aktivieren, müssen Sie zum Menü Extras gehen, auf Optionen klicken und dann unter Debuggen Bearbeiten und fortfahren suchen). Diese Funktion funktioniert in Web Site.ASP.NET MVC nicht, wenn Sie Webanwendungen mit verwenden möchten

ASP.NET MVC (Model View Controller) Die beste und Standardoption ist Webanwendung. Obwohl es möglich ist, MVC auf einer Website zu verwenden, wird dies nicht empfohlen.

Zusammenfassung - Der wichtigste Unterschied zwischen ASP.NET-Webanwendung und Website ist die Kompilierung. Wenn Sie also an einem größeren Projekt arbeiten, an dem einige Personen Änderungen vornehmen können, ist es besser, die Website zu verwenden. Wenn Sie jedoch ein kleineres Projekt ausführen, können Sie auch die Webanwendung verwenden.

Ja, Webanwendungen sind viel besser als Websites, da Webanwendungen uns Freiheit geben:

1. Mehrere Projekte unter einem Dach haben und Projektabhängigkeiten zwischen ihnen herstellen. ZB für PCS können wir folgende innerhalb der Webanwendung haben-

   • Webportale
   • Notification Controller (zum Senden von E-Mails)
   • Geschäftsschicht
   • Datenzugriffsschicht
   • Ausnahmemanager
   • Server-Dienstprogramm
   • WCF-Dienste (gemeinsam für alle Plattformen)
   • Listenpunkt

2. Ausführen von Komponententests für Code in den Klassendateien, die ASP.NET-Seiten zugeordnet sind

3. Verweisen auf die Klassen, die Seiten und Benutzersteuerelementen aus eigenständigen Klassen zugeordnet sind
4. So erstellen Sie eine einzelne Baugruppe für die gesamte Site
5. Kontrolle über den Assemblynamen und die Versionsnummer, die für die Site generiert werden
6. Um zu vermeiden, dass Quellcode auf einem Produktionsserver abgelegt wird. (Sie können die Bereitstellung von Quellcode auf dem IIS-Server vermeiden. In einigen Szenarien, z. B. in gemeinsam genutzten Hosting-Umgebungen, sind Sie möglicherweise besorgt über den nicht autorisierten Zugriff auf den Quellcode auf dem IIS-Server. (Bei einem Website-Projekt können Sie dieses Risiko vermeiden, indem Sie Vorkompilieren auf einem Entwicklungscomputer und Bereitstellen der generierten Assemblys anstelle des Quellcodes. In diesem Fall verlieren Sie jedoch einige der Vorteile einfacher Site-Updates.)
7. Leistungsproblem mit der Website (Bei der ersten Anforderung an die Website muss die Website möglicherweise kompiliert werden, was zu einer Verzögerung führen kann. Wenn die Website auf einem IIS-Server mit wenig Arbeitsspeicher ausgeführt wird, einschließlich der gesamten Website in a Eine einzelne Baugruppe benötigt möglicherweise mehr Speicher als für mehrere Baugruppen erforderlich wäre.)

Einer der Hauptunterschiede besteht darin, dass Websites dynamisch kompiliert und On-the-Fly-Assemblys erstellt werden. Webanwendungen werden zu einer großen Baugruppe kompiliert.

Die Unterscheidung zwischen beiden wurde in Visual Studio 2008 aufgehoben.

Anwendungen werden normalerweise vor der Bereitstellung kompiliert, wenn die Website das Verzeichnis app_code verwendet. Wenn sich im App-Code-Ordner etwas ändert, kompiliert der Server den Code neu. Dies bedeutet, dass Sie Code mit einer Website im laufenden Betrieb hinzufügen / ändern können.

Der Vorteil einer App besteht darin, dass keine Neukompilierung erfolgt und die ersten Startzeiten kürzer sind.

Ich empfehle Ihnen, das Video Webanwendungsprojekte und Webbereitstellungsprojekte auf der ASP.NET-Website anzusehen, in dem der Unterschied ausführlich erläutert wird. Es war für mich sehr hilfreich.

Übrigens, lassen Sie sich nicht vom Titel verwirren. Ein großer Teil des Videos erklärt den Unterschied zwischen Website-Projekten und Webanwendungsprojekten und warum Microsoft Webanwendungsprojekte in Visual Studio 2005 wieder eingeführt hat (wie Sie wahrscheinlich bereits wissen) ursprünglich nur mit Website-Projekten ausgeliefert, dann wurden Webanwendungsprojekte in SP1 hinzugefügt). Ein großartiges Video, das ich jedem empfehlen kann, der den Unterschied wissen möchte.

Eine "Website" hat ihren Code in einem speziellen App_Code-Verzeichnis und wird zur Laufzeit in mehrere DLLs (Assemblys) kompiliert. Eine "Webanwendung" wird in einer einzigen DLL vorkompiliert.

Website und Project >> Website sind zwei verschiedene Methoden zum Erstellen einer ASP.NET-Anwendung mit Visual Studio. Eines ist projektlos und ein anderes ist die Projektumgebung. Unterschiede sind wie

1. Die Lösungsdatei wird im selben Verzeichnis wie das Stammverzeichnis in der Projektumgebung gespeichert.
2. Vor der Bereitstellung in der Projektumgebung müssen Lösungs- und Projektdateien entfernt werden.
3. Das vollständige Stammverzeichnis wird in einer projektlosen Umgebung bereitgestellt.

Es gibt keinen großen grundsätzlichen Unterschied bei der Verwendung beider Ansätze. Wenn Sie jedoch eine Website erstellen, die länger dauert, entscheiden Sie sich für die Projektumgebung.

Webanwendungsprojektmodell

• Bietet dieselbe Webprojektsemantik wie Visual Studio .NET-Webprojekte. Hat eine Projektdatei (Struktur basierend auf Projektdateien). Modell erstellen - Der gesamte Code im Projekt wird in einer einzigen Assembly kompiliert. Unterstützt sowohl IIS als auch den integrierten ASP.NET Development Server. Unterstützt alle Funktionen von Visual Studio 2005 (Refactoring, Generika usw.) und von ASP.NET (Masterseiten, Mitgliedschaft und Anmeldung, Site-Navigation, Themen usw.). Die Verwendung von FrontPage Server Extensions (FPSE) ist nicht mehr erforderlich.

Website-Projektmodell

• Keine Projektdatei (basierend auf dem Dateisystem).
• Neues Kompilierungsmodell.
• Dynamisches Kompilieren und Bearbeiten von Seiten, ohne bei jeder Seitenansicht die gesamte Site zu erstellen.
• Unterstützt sowohl IIS als auch den integrierten ASP.NET Development Server.
• Jede Seite hat eine eigene Baugruppe.
• Unterschiedliches Codemodell.

Dies hängt immer von den Anforderungen Ihres Kunden ab. ASP.NET enthält lediglich flexible Funktionen, die der Benutzer für die Sicherheit und einfache Wartung Ihrer Anwendung benötigt.

Sie können sich eine Webanwendung als eine Binärdatei vorstellen, die im ASP.NET-Framework ausgeführt wird. Und Websites als statische Webseite, auf der Sie den Quellcode überprüfen und problemlos bereitstellen können.

Die Vor- und Nachteile dieser beiden ASP.NET-Technologien sind jedoch gut.

Websites - Es wird keine Lösungsdatei erstellt. Wenn wir Websites erstellen möchten, ist kein Visual Studio erforderlich.

Webanwendung - Eine Lösungsdatei wird erstellt. Wenn wir eine Webanwendung erstellen möchten, sollte das Visual Studio benötigt werden. Es wird eine einzelne .dllDatei im Ordner bin erstellt.

In Webanwendungsprojekten benötigt Visual Studio zusätzliche Designer-Dateien für Seiten und Benutzersteuerelemente. Website-Projekte erfordern diesen Overhead nicht. Das Markup selbst wird als Design interpretiert.

WebSite: Der Ordner app_code wird automatisch generiert. Wenn Sie ihn auf dem Server veröffentlichen und danach einige Änderungen an einer bestimmten Datei oder Seite vornehmen, müssen Sie nicht alle Dateien kompilieren.

Webanwendung Es wird automatisch eine Lösungsdatei generiert, die von der Website nicht generiert wird. Wenn Sie eine Datei ändern, müssen Sie das vollständige Projekt kompilieren, um die Änderungen widerzuspiegeln.

In einer Webanwendung können Sie die Ebenen der Funktionalität Ihres Projekts erstellen und Abhängigkeiten zwischen ihnen erstellen, indem Sie sie in viele Projekte aufteilen. Dies ist jedoch auf einer Website niemals möglich.

Auf jeden Fall Webanwendung, einzelne DLL-Datei und einfach zu pflegen. Eine Website ist jedoch flexibler. Sie können die Aspx-Datei unterwegs bearbeiten.

Webanwendungen benötigen mehr Speicher, vermutlich weil Sie keine andere Wahl haben, als in einer einzigen Assembly zu kompilieren. Ich habe gerade eine große Legacy-Site in eine Webanwendung konvertiert und habe Probleme mit dem Speichermangel, beide zur Kompilierungszeit mit der folgenden Fehlermeldung:

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

Fehler und zur Laufzeit mit dieser Fehlermeldung wie folgt:

Exception information: 
    Exception type: HttpException 
    Exception message: Exception of type 'System.OutOfMemoryException' was thrown.
   at System.Web.Compilation.BuildManager.ReportTopLevelCompilationException()

Meine Empfehlung für die Konvertierung größerer Websites auf speicherbeschränkter Legacy-Hardware lautet, die Option zum Zurücksetzen auf das Website-Modell zu wählen. Auch nach einem anfänglichen Erfolg kann sich später ein Problem ergeben.

Hier ist die Web Supportive Application ein Beispiel für eine Website. Website und Webanwendung können beide dynamisch / statisch sein. Dies hängt von den Anforderungen ab. Hier ist ein Beispiel, um die Funktionsweise von Websites und Webanwendungen zu verstehen.

Um einige der obigen Antworten zusammenzufassen:

Flexibilität , können Sie Live-Änderungen an einer Webseite vornehmen?

Website : Möglich. Pro: kurzfristige Vorteile. Con: Langzeitrisiko des Projektchaos.

Web App : Con: nicht möglich. Bearbeiten Sie eine Seite, archivieren Sie die Änderungen an der Quellcodeverwaltung und erstellen und implementieren Sie die gesamte Site. Pro: ein Qualitätsprojekt pflegen.

Entwicklungsprobleme

Website : Einfache Projektstruktur ohne .csproj-Datei. Zwei .aspx-Seiten können ohne Konflikte denselben Klassennamen haben. Zufälliger Projektverzeichnisname, der zu Erstellungsfehlern führt, z. B. warum .net Framework mit seiner eigenen generierten Datei in Konflikt steht und warum .net Framework mit seiner eigenen generierten Datei in Konflikt steht . Pro: Einfach (simpel). Con: unberechenbar.

Web App : Projektstruktur ähnlich dem WebForms-Projekt mit einer .csproj-Datei. Klassennamen von Asp-Seiten müssen eindeutig sein. Pro: Einfach (klug). Con: keine, weil eine Web-App immer noch einfach ist.