• 12/01/2020
  • 6 Minuten zum Lesen
    • a
    • s
    • Y
    • g
    • P
    • +1

„Atwood‘ s Law: Jede Anwendung, die in JavaScript geschrieben, schließlich werden in JavaScript geschrieben.,“
– Jeff Atwood

Es gibt heute zwei allgemeine Ansätze zum Erstellen von Webanwendungen: herkömmliche Webanwendungen, die den größten Teil der Anwendungslogik auf dem Server ausführen, und einseitige Anwendungen (SPAs), die den größten Teil der Benutzeroberflächenlogik in einem Webbrowser ausführen und mit dem Webserver hauptsächlich über Web-APIs kommunizieren. Ein hybrider Ansatz ist ebenfalls möglich, wobei der einfachste darin besteht, eine oder mehrere umfangreiche SPA-ähnliche Unteranwendungen in einer größeren herkömmlichen Webanwendung zu hosten.,

Verwenden Sie herkömmliche Webanwendungen, wenn:

  • Die clientseitigen Anforderungen Ihrer Anwendung einfach oder sogar schreibgeschützt sind.

  • Ihre Anwendung muss in Browsern ohne JavaScript-Unterstützung funktionieren.

  • Ihr Team ist mit JavaScript-oder TypeScript-Entwicklungstechniken nicht vertraut.

Verwenden Sie ein SPA, wenn:

  • Ihre Anwendung eine umfangreiche Benutzeroberfläche mit vielen Funktionen bereitstellen muss.

  • Ihr Team ist mit der Entwicklung von JavaScript, TypeScript oder Blazor WebAssembly vertraut.,

  • Ihre Anwendung muss bereits eine API für andere (interne oder öffentliche) Clients bereitstellen.

Darüber hinaus erfordern SPA-Frameworks mehr Architektur-und Sicherheitsexpertise. Sie erleben eine größere Abwanderung durch häufige Updates und neue Frameworks als herkömmliche Webanwendungen. Das Konfigurieren automatisierter Build – und Bereitstellungsprozesse und die Verwendung von Bereitstellungsoptionen wie Containern können bei SPA-Anwendungen schwieriger sein als bei herkömmlichen Web-Apps.

Verbesserungen der Benutzererfahrung, die durch den SPA-Ansatz ermöglicht werden, müssen gegen diese Überlegungen abgewogen werden.,

Blazor

ASP.NET Core enthält ein Modell zum Erstellen umfangreicher, interaktiver und zusammensetzbarer Benutzeroberflächen namens Blazor. Blazor serverseitig ermöglicht es Entwicklern, eine Benutzeroberfläche mit C# und Razor auf dem Server zu erstellen und die Benutzeroberfläche mithilfe einer persistenten SignalR-Verbindung in Echtzeit interaktiv mit dem Browser zu verbinden. Blazor WebAssembly führt eine weitere Option für Blazor-Apps ein, mit der sie mit WebAssembly im Browser ausgeführt werden können. Da es sich um echtes. NET handelt, das auf WebAssembly ausgeführt wird, können Sie Code und Bibliotheken aus serverseitigen Teilen Ihrer Anwendung wiederverwenden.,

Blazor bietet eine neue, dritte Option, die bei der Bewertung zu berücksichtigen ist, ob eine rein servergerenderte Webanwendung oder ein SPA erstellt werden soll. Sie können mit Blazor umfangreiche, SPA-ähnliche clientseitige Verhaltensweisen erstellen, ohne dass eine signifikante JavaScript-Entwicklung erforderlich ist. Blazor-Anwendungen können APIs aufrufen, um Daten anzufordern oder serverseitige Vorgänge auszuführen. Sie können bei Bedarf mit JavaScript zusammenarbeiten, um JavaScript-Bibliotheken und-Frameworks zu nutzen.,

Erwägen Sie, Ihre Webanwendung mit Blazor zu erstellen, wenn:

  • Ihre Anwendung eine reichhaltige Benutzeroberfläche bereitstellen muss

  • Ihr Team ist mit der.NET-Entwicklung wohler als mit JavaScript oder TypeScript-Entwicklung

Wenn Sie eine vorhandene Webformularanwendung haben, die Sie in Betracht ziehen, auf. NET Core oder das neueste. NET zu migrieren, möchten Sie möglicherweise das kostenlose E-Book Blazor for Web Forms Developers überprüfen, um festzustellen, es ist sinnvoll, die Migration auf Blazor in Betracht zu ziehen.

Weitere Informationen zu Blazor finden Sie unter Erste Schritte mit Blazor.,

Wenn traditionelle Web-Apps wählen

Der folgende Abschnitt ist eine detailliertere Erklärung der zuvor genannten Gründe für traditionelle Web-Anwendungen Kommissionierung.

Ihre Anwendung hat einfache, möglicherweise schreibgeschützte clientseitige Anforderungen

Viele Webanwendungen werden hauptsächlich schreibgeschützt von der überwiegenden Mehrheit ihrer Benutzer verwendet. Schreibgeschützte (oder meist lesbare) Anwendungen sind in der Regel viel einfacher als Anwendungen, die viel Status verwalten und bearbeiten., Beispielsweise kann eine Suchmaschine aus einem einzelnen Einstiegspunkt mit einem Textfeld und einer zweiten Seite zum Anzeigen von Suchergebnissen bestehen. Anonyme Benutzer können problemlos Anfragen stellen, und es besteht wenig Bedarf an clientseitiger Logik. Ebenso besteht die öffentlich zugängliche Anwendung eines Blogs oder Content-Management-Systems in der Regel hauptsächlich aus Inhalten mit wenig clientseitigem Verhalten. Solche Anwendungen können leicht als herkömmliche serverbasierte Webanwendungen erstellt werden, die Logik auf dem Webserver ausführen und HTML rendern, um im Browser angezeigt zu werden., Die Tatsache, dass jede eindeutige Seite der Site über eine eigene URL verfügt, die von Suchmaschinen mit einem Lesezeichen versehen und indiziert werden kann (standardmäßig ohne diese Funktionalität als separate Funktion der Anwendung hinzufügen zu müssen), ist auch in solchen Szenarien ein klarer Vorteil.

Ihre Anwendung muss in Browsern ohne JavaScript-Unterstützung funktionieren

Webanwendungen, die in Browsern mit eingeschränkter oder keiner JavaScript-Unterstützung funktionieren müssen, sollten mit herkömmlichen Web-App-Workflows geschrieben werden (oder zumindest auf ein solches Verhalten zurückgreifen können)., SPAs erfordern clientseitiges JavaScript, um zu funktionieren; Wenn es nicht verfügbar ist, sind SPAs keine gute Wahl.

Ihr Team ist mit JavaScript-oder TypeScript-Entwicklungstechniken nicht vertraut

Wenn Ihr Team mit JavaScript oder TypeScript nicht vertraut ist, aber mit der serverseitigen Webanwendungsentwicklung vertraut ist, können sie wahrscheinlich eine herkömmliche Webanwendung schneller bereitstellen als ein SPA., Es sei denn, das Programmieren von SPAs ist ein Ziel oder die Benutzererfahrung, die ein SPA bietet, ist erforderlich, Herkömmliche Web-Apps sind eine produktivere Wahl für Teams, die bereits mit dem Erstellen von SPAs vertraut sind.

Wann Sie SPAs auswählen

Im folgenden Abschnitt finden Sie eine detailliertere Erklärung, wann Sie einen einzelnen Seitenanwendungsstil für Ihre Webanwendung auswählen müssen.,

Ihre Anwendung muss eine umfangreiche Benutzeroberfläche mit vielen Funktionen bereitstellen

SPAs können umfangreiche clientseitige Funktionen unterstützen, für die kein erneutes Laden der Seite erforderlich ist, wenn Benutzer Aktionen ausführen oder zwischen Bereichen der App navigieren. SPAs können schneller geladen werden, Daten im Hintergrund abgerufen werden und einzelne Benutzeraktionen reagieren reaktionsschneller, da ganzseitige Neuladungen selten sind. SPAs können inkrementelle Aktualisierungen unterstützen und teilweise ausgefüllte Formulare oder Dokumente speichern, ohne dass der Benutzer auf eine Schaltfläche zum Senden eines Formulars klicken muss., SPAs können umfangreiche clientseitige Verhaltensweisen wie Drag-and-Drop viel einfacher unterstützen als herkömmliche Anwendungen. SPAs können so konzipiert werden, dass sie in einem getrennten Modus ausgeführt werden und Aktualisierungen an einem clientseitigen Modell vornehmen, die nach dem erneuten Herstellen einer Verbindung schließlich wieder mit dem Server synchronisiert werden. Wählen Sie eine Anwendung im SPA-Stil, wenn die Anforderungen Ihrer App umfangreiche Funktionen umfassen, die über das hinausgehen, was typische HTML-Formulare bieten.,

Häufig müssen Sie Funktionen implementieren, die in herkömmlichen Web-Apps integriert sind, z. B. das Anzeigen einer aussagekräftigen URL in der Adressleiste, die den aktuellen Vorgang widerspiegelt (und es Benutzern ermöglicht, Lesezeichen zu setzen oder eine Deep-Link-Verbindung zu dieser URL herzustellen). SPAs sollten es Benutzern auch ermöglichen, die Vor-und Zurückschaltflächen des Browsers mit Ergebnissen zu verwenden, die sie nicht überraschen.

Ihr Team ist mit JavaScript und/oder TypeScript-Entwicklung vertraut

Das Schreiben von SPAs erfordert die Vertrautheit mit JavaScript und / oder TypeScript sowie clientseitigen Programmiertechniken und Bibliotheken., Ihr Team sollte kompetent sein, modernes JavaScript mit einem SPA-Framework wie Angular zu schreiben.

Ihre Anwendung muss bereits eine API für andere (interne oder öffentliche) Clients bereitstellen

Wenn Sie bereits eine Web-API für die Verwendung durch andere Clients unterstützen, ist möglicherweise weniger Aufwand erforderlich Erstellen Sie eine SPA-Implementierung, die diese APIs nutzt, anstatt die Logik in serverseitiger Form zu reproduzieren. SPAs verwenden Web-APIs umfassend, um Daten abzufragen und zu aktualisieren, während Benutzer mit der Anwendung interagieren.,

Wenn Blazor wählen

Der folgende Abschnitt ist eine detailliertere Erklärung, wann Blazor für Ihre Web-App wählen.

Ihre Anwendung muss eine reichhaltige Benutzeroberfläche bereitstellen

Wie JavaScript-basierte SPAs können Blazor-Anwendungen das Verhalten von Rich Clients ohne erneutes Laden der Seite unterstützen. Diese Anwendungen reagieren besser auf Benutzer und rufen nur die Daten (oder HTML) ab, die für die Reaktion auf eine bestimmte Benutzerinteraktion erforderlich sind. Ordnungsgemäß entwickelt, können serverseitige Blazor-Apps so konfiguriert werden, dass sie als clientseitige Blazor-Apps mit minimalen Änderungen ausgeführt werden, sobald diese Funktion unterstützt wird.,

Ihr Team ist mit. NET-Entwicklung wohler als JavaScript oder TypeScript-Entwicklung

Viele Entwickler sind produktiver mit. NET und Razor als mit clientseitigen Sprachen wie JavaScript oder TypeScript. Da die Serverseite der Anwendung bereits mit. NET entwickelt wird, stellt die Verwendung von Blazor sicher, dass jeder.NET-Entwickler im Team das Verhalten des Frontends der Anwendung verstehen und möglicherweise erstellen kann.,

Entscheidungstabelle

Die folgende Entscheidungstabelle fasst einige der grundlegenden Faktoren zusammen, die bei der Auswahl zwischen einer herkömmlichen Webanwendung, einem SPA oder einer Blazor-App zu berücksichtigen sind.,

Erforderlich Team Vertrautheit mit JavaScript/TypeScript Minimal Erforderlich Minimal Unterstützung Browser ohne Scripting Unterstützt Nicht Unterstützt Unterstützt Minimales clientseitiges Anwendungsverhalten Gut geeignet Overkill Gut geeignet Umfangreiche, komplexe Benutzeroberflächenanforderungen Begrenzt Gut geeignet Gut geeignet

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.