asp.net - mvc - mvs asp net




ASP.NET-Website oder ASP.NET-Webanwendung? (17)

Compilation Zunächst gibt es einen Unterschied in der Zusammenstellung. Die Website ist nicht auf dem Server vorkompiliert, sie ist in einer Datei kompiliert. Es kann ein Vorteil sein, denn wenn Sie etwas auf Ihrer Website ändern möchten, können Sie einfach eine bestimmte Datei vom Server herunterladen, ändern und diese Datei zurück auf den Server hochladen und alles würde gut funktionieren. In Web-Anwendung können Sie dies nicht tun, weil alles vorkompiliert ist und Sie nur mit einer DLL enden. Wenn Sie etwas in einer Datei Ihres Projekts ändern, müssen Sie alles erneut kompilieren. Also, wenn Sie eine Möglichkeit haben möchten, einige Dateien auf der Server-Website zu ändern, ist eine bessere Lösung für Sie. Es ermöglicht auch vielen Entwicklern, auf einer Website zu arbeiten. Auf der anderen Seite sollten Sie, wenn Sie nicht möchten, dass Ihr Code auf dem Server verfügbar ist, die Webanwendung wählen. Diese Option eignet sich auch besser für Komponententests, da nach dem Veröffentlichen Ihrer Website eine DLL-Datei erstellt wird.

Project structure Es gibt auch einen Unterschied in der Struktur des Projekts. In der Web Application haben Sie eine Projektdatei, so wie Sie sie in der normalen Anwendung hatten. In der Website gibt es keine traditionelle Projektdatei, Sie haben nur eine Lösungsdatei. Alle Verweise und Einstellungen sind in der Datei web.config gespeichert. @Page directive Es gibt ein anderes Attribut in der @ Page-Direktive für die Datei, die die Klasse enthält, die dieser Seite zugeordnet ist. In Web-Anwendung ist es Standard "CodeBehind", in der Website verwenden Sie "CodeFile". Sie können dies in den folgenden Beispielen sehen:

Web Application:

<%@ 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 auch einen anderen Unterschied - wie Namespaces erstellt werden. Im Web Application-Namespace ist einfach ein Name des Projekts. In der Website gibt es den Standard-Namespace-ASP für dynamisch kompilierte Seiten.

Edit and Continue - In der Web Application Edit und Continue-Option ist verfügbar (um es zu aktivieren, müssen Sie im Menü Extras, klicken Sie auf Optionen, dann finden Sie Bearbeiten und Weiter im Debuggen). Diese Funktion funktioniert nicht in Web Site.ASP.NET MVCIf, mit der Sie Webanwendungen entwickeln möchten

ASP.NET MVC (Model View Controller) die beste und Standardoption ist Web Application. Obwohl es möglich ist, MVC in der Website zu verwenden, wird es nicht empfohlen.

Zusammenfassung - Der wichtigste Unterschied zwischen der ASP.NET-Webanwendung und der 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. Aber wenn Sie ein kleineres Projekt machen, können Sie auch die Web-Anwendung verwenden.

Wenn ich ein neues ASP.NET-Projekt in Visual Studio starte, kann ich eine ASP.NET-Webanwendung erstellen 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 wählen?

Ist die Antwort abhängig davon, welche Version von Visual Studio ich verwende, unterschiedlich?


Anwendungen werden in der Regel vor der Bereitstellung kompiliert, da die Website das Verzeichnis app_code verwendet. Wenn sich im App-Code-Ordner etwas ändert, kompiliert der Server den Code erneut. 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 erforderlich ist und die anfänglichen Startzeiten schneller sind.


Das klingt vielleicht einleuchtend, aber ich denke, dass es etwas missverstanden ist, weil Visual Studio 2005 ursprünglich nur mit der Website geliefert wurde. Wenn Ihr Projekt eine Website betrifft, die ziemlich begrenzt ist und keine große logische oder physische Trennung aufweist, ist die Website in Ordnung. Wenn es sich jedoch wirklich um eine Webanwendung mit verschiedenen Modulen handelt, bei denen viele Benutzer Daten hinzufügen und aktualisieren, ist die Webanwendung besser.

Der größte app_code des Website-Modells ist, dass alles im Abschnitt app_code dynamisch kompiliert wird. Sie können Aktualisierungen der C # -Datei ohne eine vollständige erneute Bereitstellung vornehmen. Dies ist jedoch ein großes Opfer. Unter den schwer kontrollierbaren Abdeckungen passieren viele Dinge. Namespaces sind schwer zu kontrollieren, und die spezifische DLL-Verwendung wird standardmäßig für alles unter app_code da alles dynamisch kompiliert wird.

Das Webanwendungsmodell hat keine dynamische Kompilierung, aber Sie haben die Kontrolle über die Dinge, die ich erwähnt habe.

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

Eine detailliertere Analyse finden Sie in:


Definitiv Web-Anwendung, einzelne DLL-Datei und einfach zu pflegen. Aber eine Website ist flexibler; Sie können die aspx-Datei unterwegs bearbeiten.


Einer der Hauptunterschiede besteht darin, dass Websites dynamisch kompiliert und On-The-Fly-Assemblys erstellt werden. Web-Anwendungen werden in einer großen Assembly kompiliert.

Die Unterscheidung zwischen den beiden wurde in Visual Studio 2008 aufgehoben.



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

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

Aber die Vorteile und Nachteile dieser beiden ASP.NET-Technologien kommen, was gut ist.


Ich empfehle Ihnen, das Video Web Application Projects und Web Deployment Projects auf der ASP.NET-Website zu betrachten, das den Unterschied im Detail erklärt, es war sehr hilfreich für mich.

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


In einer Webanwendung können Sie die Ebenen der Projektfunktionalität erstellen und Abhängigkeiten zwischen ihnen erstellen, indem Sie sie in viele Projekte aufteilen. Dies können Sie jedoch nie auf einer Website tun.


Ja Web-Anwendung ist viel besser als Websites, weil Web-Anwendungen uns Freiheit geben:

  1. Um mehrere Projekte unter einem Dach zu haben und Projektabhängigkeiten herzustellen. ZB für PCS können wir folgende Webanwendungen haben:

    • Webportale
    • Benachrichtigungs-Controller (zum Senden von E-Mails)
    • Geschäftsschicht
    • Datenzugriffsschicht
    • Ausnahmemanager
    • Server-Dienstprogramm
    • WCF-Dienste (allgemein für alle Plattformen)
    • Listenpunkt
  2. So führen Sie Komponententests für Code aus, der sich in den Klassendateien befindet, die ASP.NET-Seiten zugeordnet sind

  3. Um auf die Klassen zu verweisen, die mit Seiten und Benutzersteuerelementen aus eigenständigen Klassen verknüpft sind
  4. So erstellen Sie eine einzelne Assembly für die gesamte Site
  5. Steuern Sie den Assemblynamen und die Versionsnummer, die für die Site generiert werden
  6. Um zu vermeiden, dass Quellcode auf einen Produktionsserver gestellt wird. (Sie können die Bereitstellung von Quellcode für den IIS - Server vermeiden. In einigen Szenarien, wie z. B. Shared Hosting - Umgebungen, sind Sie möglicherweise über nicht autorisierten Zugriff auf Quellcode auf dem IIS - Server besorgt. (Bei einem Website - Projekt können Sie dieses Risiko vermeiden Vorkompilieren auf einem Entwicklungscomputer und Bereitstellen der generierten Assemblies anstelle des Quellcodes. In diesem Fall verlieren Sie jedoch einige der Vorteile von einfachen Websiteaktualisierungen.)
  7. Leistungsproblem mit der Website (Die erste Anforderung an die Website erfordert möglicherweise die Kompilierung der Site, was zu einer Verzögerung führen kann. Und wenn die Website auf einem IIS-Server mit wenig Arbeitsspeicher ausgeführt wird, einschließlich der gesamten Website in einer Eine einzelne Assembly benötigt möglicherweise mehr Speicher als für mehrere Assemblies erforderlich wäre.)

Um einige der Antworten oben zusammenzufassen:

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

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

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

Entwicklungsprobleme

Website : Einfache Projektstruktur ohne CSPROJ-Datei. Zwei ASPX-Seiten können denselben Klassennamen ohne Konflikte haben. Zufälliger Name des Projektverzeichnisses, das zu Fehlern beim Erstellen führt, z. B. warum .NET Framework mit seiner eigenen generierten Datei in Konflikt gerät und warum .NET Framework mit seiner eigenen generierten Datei in Konflikt gerät . Pro: Einfach (simpel). Con: sprunghaft.

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


Webanwendungen benötigen mehr Arbeitsspeicher, vermutlich weil Sie keine andere Wahl haben, als in eine einzelne Assembly zu kompilieren. Ich habe gerade eine große Legacy-Site in eine Web-Anwendung umgewandelt und habe Probleme, dass nicht genügend Arbeitsspeicher zur Verfügung steht

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

Fehler und zur Laufzeit mit diesem Fehler:

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 Sites auf Alias-Hardware mit Speicherbeschränkung ist, dass Sie die Möglichkeit haben, auf das Websitemodell zurückzugreifen. Auch nach einem anfänglichen Erfolg könnten später Probleme auftreten.


Websites - Es wird keine Lösungsdatei erstellt. Wenn wir Websites erstellen möchten, brauchen Sie kein visuelles Studio.

Web Application - Eine Lösungsdatei wird erstellt. Wenn wir Webanwendungen erstellen möchten, sollten Sie das Visual Studio benötigen. Es wird eine einzelne .dll Datei im bin-Ordner erstellt.


Hier ist Web Supportive Application ein Beispiel für eine Website. Website und Web-Anwendung können beide dynamisch / statisch sein, es hängt von den Anforderungen ab, hier ist ein Beispiel, um das Arbeiten der Website und Web-Anwendung zu verstehen.


Die Website wird auf einem ASP.NET-Webserver wie IIS bereitgestellt. Nur ein paar Dateien und Ordner. Es gibt nichts auf einer Website, das Sie an Visual Studio bindet (es gibt keine Projektdatei). Code-Generierung und Kompilierung von Webseiten (wie .aspx, .ascx, .master) erfolgt dynamisch zur Laufzeit , und Änderungen an diesen Dateien werden vom Framework erkannt und automatisch neu kompiliert. Sie können Code, den Sie freigeben möchten, zwischen Seiten im speziellen Ordner App_Code platzieren, oder Sie können ihn vorab kompilieren und die Assembly in den Ordner Bin stellen.

Web Application ist ein spezielles Visual Studio-Projekt. Der Hauptunterschied zu Websites besteht darin, dass beim Erstellen des Projekts alle Codedateien in eine einzelne Assembly kompiliert werden, die im Verzeichnis bin abgelegt wird. Sie stellen keine Code-Dateien auf dem Webserver bereit. Anstatt einen speziellen Ordner für gemeinsam genutzte Code-Dateien zu haben, können Sie sie überallhin platzieren, genau wie in der Klassenbibliothek. Da Webanwendungen Dateien enthalten, die nicht bereitgestellt werden sollen, z. B. Projekt- und Codedateien, gibt es in Visual Studio einen Befehl zum Publish um eine Website an einen bestimmten Speicherort auszugeben.

App_Code vs Bin

Das Bereitstellen von freigegebenen Codedateien ist normalerweise eine schlechte Idee, aber das bedeutet nicht, dass Sie Webanwendung auswählen müssen. Sie können eine Website erstellen, die auf ein Klassenbibliotheksprojekt verweist, das den gesamten Code für die Website enthält. Web-Anwendungen 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 Code-Dateien in eine einzelne Assembly kompiliert haben, einschließlich der 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 die Änderungen ständig neu erstellen müssen, während bei Websites Änderungen von der Laufzeit erkannt werden und Seiten / Steuerelemente automatisch neu kompiliert werden.

Das Verwalten der Codebehind-Assemblys durch die Laufzeit ist für Sie weniger arbeitsaufwendig, da Sie sich keine Gedanken darüber machen müssen, wie Sie eindeutigen Seiten / Steuerelementen Namen geben oder sie in verschiedenen Namespaces organisieren.

Ich sage nicht, das Bereitstellen von Code-Dateien ist immer eine gute Idee (speziell nicht im Fall von gemeinsam genutzten Code-Dateien), aber CodeBehind-Dateien sollten nur Code enthalten, die UI-spezifische Aufgaben, Draht-Event-Handler usw. Ihre Anwendung sollte sein so dass wichtiger Code immer im Bin-Ordner landet. Wenn dies der Fall ist, sollte die Bereitstellung von Codebehind-Dateien nicht als schädlich angesehen werden.

Eine weitere Einschränkung von Web-Anwendungen besteht darin, dass Sie nur die Sprache des Projekts verwenden können. In Websites können Sie einige Seiten in C #, einige in VB, etc. haben. Keine Notwendigkeit für spezielle Visual Studio-Unterstützung. Das ist die Schönheit der Erweiterbarkeit des Build-Providers.

Außerdem erhalten Sie in Web Applications keine Fehlererkennung in Pages / Controls, da der Compiler nur Ihre CodeBehind-Klassen kompiliert und nicht den Markup-Code (in MVC können Sie dies mit der Option MvcBuildViews beheben), der zur Laufzeit kompiliert wird.

Visual Studio

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

Ein weiteres nettes Feature in Visual Studio 2010 ist die Web.config-Umwandlung . Dies ist auch nicht in Websites verfügbar. Funktioniert jetzt mit Websites in VS 2013.

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

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

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

Die NuGet-Paketwiederherstellung funktioniert nicht auf Websites. Sie müssen die in der Datei packages.config aufgeführten Pakete manuell installieren Die Paketwiederherstellung funktioniert jetzt mit Websites , auf denen NuGet 2.7 gestartet wird


Web Application-Projektmodell

  • Stellt die gleiche Webprojektsemantik wie Visual Studio .NET-Webprojekte bereit. Hat eine Projektdatei (Struktur basiert auf Projektdateien). Modell erstellen - Der gesamte Code im Projekt wird in einer einzelnen Assembly kompiliert. Unterstützt sowohl IIS als auch den integrierten ASP.NET Development Server. Unterstützt alle Funktionen von Visual Studio 2005 (Refactoring, Generics usw.) und von ASP.NET (Masterseiten, Mitgliedschaft und Login, Websitenavigation, Themen usw.). Die Verwendung von FrontPage-Servererweiterungen (FPSE) ist nicht mehr erforderlich.

Website-Projektmodell

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

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

Web Application = Wird verwendet, 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 benötigt wird, da Projektdateien nicht aktualisiert werden müssen. Webanwendungen sind am besten, wenn das Team hauptsächlich Entwicklerstudio verwendet und ein hoher Code-Inhalt vorhanden ist.

(Einige Codierungsfehler werden in Webanwendungen zur Kompilierungszeit gefunden, die bis zur Laufzeit nicht in Websites gefunden werden.)

Warnung: Ich habe diese Antwort vor vielen Jahren geschrieben und seither Asp.net nicht mehr benutzt. Ich gehe davon aus, dass sich die Dinge jetzt weiter entwickelt haben.





projects-and-solutions