Erstellen von Webanwendungen

Frontend-Architektur mit Blazor Web App

Von Lino generierte Webanwendungen verbinden Benutzer über eine echte Schnittstelle mit Backend-Anwendungsfällen, nicht nur über Aufrufe an API-Tools. Der aktuelle native Frontend-Typ ist Blazor Web-App, vorbereitet für Verwaltungsanwendungen, öffentliche Portale, Backoffices, Partnerbereiche und domänenspezifische Schnittstellen.

lino web-app new --name <WebAppName>

Der Befehl muss innerhalb eines Lino-Projekts ausgeführt werden. Es fordert den Namen der Web App an, verwendet die Blazor Web App-Vorlage, bestätigt die ausgewählten Daten, erstellt die erforderlichen Dateien und führt die Befehle aus, die das Frontend mit der Lösung verbinden. Die kanonische Form ist web-app. Die Aliase webapp Und web Für die Produktivität gibt es solche, aber Dokumentation und Beispiele sollten den Vorzug geben lino web-app new um die Konsistenz aufrechtzuerhalten.

Was wird generiert

Eine von Lino generierte Blazor Web App ist nicht nur ein loser Ordner mit Oberflächen. Sie wird Teil derselben .NET-Lösung und folgt der modularen Organisation des Backends, wobei Verantwortlichkeiten zwischen Host, Client, gemeinsamen Komponenten und UI-Projekten pro Dienst oder Modul getrennt werden.

• Serverprojekt: Hostet die Blazor-Web-App, ordnet die Stammkomponenten zu, konfiguriert Dienststandards, statische Assets, Fälschungsschutz, HTTPS-, MudBlazor-Dienste und interaktive Rendering-Modi.
• Client-Projekt: Konzentriert Komponenten, die auf der WebAssembly-Seite ausgeführt werden, Routing, Layout, Menüstruktur, Browsereinstellungen, Lokalisierungsfunktionen und Integration mit MudBlazor.
• Geteiltes WebApps-Projekt: Zentralisiert allgemeine UI-Ressourcen, Benachrichtigungen, Dialoge, Abfragezeichenfolgenvorlagen, Clientergebnisse, Kultur-/Zeitzonendienste und wiederverwendbare Komponenten.
• UI-Projekte pro Dienst und Modul: Wenn die Lösung über Dienste und Module verfügt, erstellt Lino Frontend-Projekte innerhalb des Web-App-Frameworks, um kontextisolierte Seiten, Menüs und Ressourcen zu verwalten.

Die generierten Host-Register AddInteractiveServerComponents Und AddInteractiveWebAssemblyComponents. Die Stammkomponenten HeadOutlet Und Routes verwenden InteractiveAutoDadurch kann die Anwendung mit Interaktivität über den Server starten und zu WebAssembly migrieren, wenn die Client-Laufzeit verfügbar ist.

Integration mit Backend APIs

Wenn eine Web-App vorhanden ist, hält Lino das Backend für die typisierte Nutzung durch das Frontend bereit. Dienste und Module können Projekte erhalten Api.Contracts Und Api.Client, wodurch Anforderungs-/Antwortverträge und typisierte Clients den generierten Endpunkten zugänglich gemacht werden.

• Die Benutzeroberfläche muss rohe HTTP-Aufrufe nicht für jede Funktionalität manuell zusammenstellen.
• Generierte Seiten rufen typisierte API-Clients auf und arbeiten mit Anforderungs- und Antwortmodellen, die zusammen mit dem Backend erstellt wurden.
• Modelle geteilt als ClientResult, QueryParams Und PagedQueryParams Standardisieren Sie die Ergebnisverarbeitung, Filter, Paginierung und visuelles Feedback.
• Die Integration über einen typisierten HttpClient hält das Frontend an Verträgen, Berechtigungen, Validierungsnachrichten und Kulturen ausgerichtet, die vom Rest der Lösung verwendet werden.

Der praktische Ablauf ist:

Blazor-Seite -> typisierter API-Client -> Minimal-API-Endpunkt -> Command/Query -> Datenbank

Dieser Pfad gewährleistet die Konsistenz des gesamten Stapels: Das Domänenmodell, die Anwendungsfälle, Endpunkte, Verträge, die lokalisierte Schnittstelle, die Navigation und die Berechtigungen folgen denselben Projektkonventionen.

UI-Funktionen enthalten

Die generierte Web App ist bereits auf die gängigen Belange realer Anwendungen vorbereitet:

• Komponentenrouting Routes.razor generiert.
• Layout, Navigation und visuelle Komponenten basierend auf MudBlazor.
• Generierung von Menüs aus den in jedem Dienst oder Modul verfügbaren Seiten.
• .resx-Dateien zur Lokalisierung von Texten in den im Projekt konfigurierten Kulturen.
• Unterstützt Authentifizierung, Tokenspeicherung, geschützte Routen und Berechtigungsdienste, wenn die Authentifizierungsfunktion aktiviert ist.
• Berechtigungsabhängige Menüs, die Einträge nur anzeigen, wenn der aktuelle Benutzer über die erforderliche Berechtigung verfügt.

Mehrere Frontends

Ein einzelnes Backend kann mehr als eine Web-App unterstützen. Dies ist nützlich, wenn unterschiedliche Zielgruppen unterschiedliche Navigation, Sicherheit, Erfahrung und Bereitstellung benötigen, aber weiterhin dieselben Dienste, Module, Anwendungsfälle und APIs nutzen müssen.

• Öffentliche Website: Seiten, die für Kunden, Besucher oder Benutzer zugänglich sind, die noch nicht authentifiziert sind.
• Backoffice/Admin: Internes Managementpanel für Bediener, Support- und Verwaltungsteams.
• Partnerportal: Eingeschränkter Zugriff für Partner, Wiederverkäufer, Lieferanten oder betriebliche Integrationen.
• Selbstbedienungsbereich: Endkundenorientiertes Erlebnis mit eigenen Menüs und Berechtigungen.

Jedes Frontend kann mit seinen eigenen Layouts, Ressourcen, Menüs und Zugriffsregeln weiterentwickelt werden, während das Backend nach Diensten, Modulen, Anwendungsfällen und Verträgen organisiert bleibt.

Erzeugen von Webseiten

Nach der Modellierung der Entität, der Definition der Anwendungsfälle und der Generierung von Befehlen, Abfragen, Endpunkten und Persistenz besteht der nächste Schritt normalerweise darin, die Funktionalität in der Schnittstelle bereitzustellen. Lino automatisiert diesen Schritt mit dem Seitengenerator:

lino page new --service <ServiceName> --module <ModuleName> --entity <EntityName> --webapp <WebAppName>
lino page edit --service <ServiceName> --module <ModuleName> --entity <EntityName> --webapp <WebAppName>
lino page list --service <ServiceName> --module <ModuleName> --entity <EntityName> --webapp <WebAppName>

Optionen können auch interaktiv informiert werden. Der Befehl fragt nach dem Dienst, dem Modul, der Entität, der Ziel-Webanwendung, dem Seitentyp und den Eigenschaften, die im Raster angezeigt werden sollen. Der häufigste Typ ist CRUD; Wenn die Entität nur Abfragen unterstützt, kann Lino eine Seite wie generieren DataGrid.

Verwenden page new um die erste Version des Bildschirms zu erstellen, page edit wenn die Seite Änderungen an Feldern, Verträgen oder Verhalten verfolgen muss und page list um zu verstehen, was bereits für eine Entität generiert wurde.

Empfohlener Durchfluss

1. Erstellen oder wählen Sie die Web-App mit aus lino web-app new.
2. Modellieren Sie die Entität und generieren Sie Anwendungsfälle, Abfragen, Befehle, Endpunkte, API-Verträge und Persistenzartefakte.
3. Laufen lino page new und wählen Sie die Entität aus, die die Schnittstelle erhalten soll.
4. Wählen Sie die Felder im Raster sorgfältig aus. Sie werden zu sichtbaren Spalten und helfen beim Einrichten von Abfrageparametern, Filtern und Paginierung.
5. Führen Sie die Lösung über AppHost aus, um UI, APIs, Authentifizierung, Berechtigungen und Datenbankintegration gemeinsam zu validieren.

Generierte Struktur

Für eine CRUD-Seite erstellt Lino ein vollständiges Blazor-Seitenpaket anstelle einer einzelnen Razor-Datei:

• Datensatzseite oder Index zur Koordinierung der Auflistung, Erstellung, Bearbeitung, Details und Löschung.
• Rasterkomponente basierend auf MudBlazor, mit serverseitigem Laden, Paginierung, Filtern und Zuordnung für Abfrageparameter.
• Formularkomponente mit typisiertem ViewModel und Erweiterungen zum Zuordnen von Erstellungs-, Aktualisierungs- und Get-by-ID-Anfragen.
• Ressourcen für Titel, Beschriftungen, Schaltflächen, Validierungsmeldungen und lokalisierte Schnittstellentexte.
• Berechtigungsprüfungen, wenn die Authentifizierung aktiviert ist, einschließlich Seitenzugriffsvalidierung und bedingte Schaltflächen.

Erstellen einer CRUD-Seite für die Entität Vehicle, zum Beispiel im Dienst Fleet, Modul Operations und Web-App Backoffice, die Struktur folgt diesem Format:

src/WebApps/Backoffice/Services/Fleet/Operations/Pages/Vehicles/Registration/
├── Vehicle.razor
├── Vehicle.razor.cs
├── Resources/
│   ├── VehicleResources.resx
│   └── VehicleResources.Designer.cs
└── Components/
    ├── Form/
    │   ├── VehicleForm.razor
    │   ├── VehicleForm.razor.cs
    │   ├── VehicleFormExtensions.cs
    │   ├── VehicleViewModel.cs
    │   └── Resources/
    │       ├── VehicleFormResources.resx
    │       └── VehicleFormResources.Designer.cs
    └── Grid/
        ├── VehicleGrid.razor
        ├── VehicleGrid.razor.cs
        ├── VehicleGridExtensions.cs
        ├── VehiclePagedQueryParams.cs
        └── Resources/
            ├── VehicleGridResources.resx
            └── VehicleGridResources.Designer.cs

Die Idee behält die vorherige Struktur bei, die in Beispielen wie verwendet wurde Order: Hauptseite, Code-Behind, Formularkomponenten, Rasterkomponenten, Erweiterungen und paginierte Parameter. Die aktuelle Version fügt Funktionen und eine explizite Integration in die Organisation nach Web-App, Dienst und Modul hinzu.

So funktioniert die generierte Seite

Die Seite verwendet dieselben Verträge, die für API generiert wurden. Das Raster wandelt Filter und Paginierung in eine Auflistungsanfrage um; Das Formular wandelt das ViewModel in Erstellungs- oder Aktualisierungsanforderungen um. Der typisierte API-Client sendet den Anruf an den entsprechenden Endpunkt. Der Endpunkt führt den generierten Befehl oder die generierte Abfrage aus und gibt eine typisierte Antwort an die Benutzeroberfläche zurück.

Frontend -> API -> Commands/Queries -> Datenbank

Bei vorhandener Berechtigung prüft der generierte Code auch Berechtigungen wie Auflisten, Erstellen, Bearbeiten, Löschen und Abfragen nach Identifikator. Dies betrifft sowohl den Zugriff auf die Seite als auch die Sichtbarkeit von Aktionen für den Benutzer.

Das Ergebnis ist ein konsistenter Full-Stack-Ablauf: Domänenmodell, Anwendungsfall, Endpunkt, typisierter Client, lokalisierte Benutzeroberfläche, Navigation und Berechtigungen folgen denselben Designkonventionen. Der Generator reduziert Wiederholungen, aber Komponenten bleiben für Produktanpassungen, Benutzerfreundlichkeit und spezifische Regeln bearbeitbar.

Mehrsprachige Benutzeroberfläche

Von Lino generierte Webanwendungen verwenden Dateien .resx für lokalisierte Texte. Dadurch können Sie die gleiche Razor-Struktur beibehalten und Titel, Beschriftungen, Schaltflächen, Fehlermeldungen, Validierungstexte und Beschreibungen je nach aktiver Kultur variieren.

Der Standort sollte nicht als optischer Abschluss betrachtet werden. Auf Verwaltungsseiten und Betriebsportalen wecken inkonsistente Begriffe Zweifel an der Geschäftsregel. Daher sind Ressourcen Teil der UI-Architektur und müssen Seiten, Formulare, Raster und gemeinsam genutzte Komponenten begleiten.

• Halten Sie die Tasten stabil, beschreibend und bedeutungsorientiert und vermeiden Sie Namen, die an das temporäre Bildschirmlayout gebunden sind.
• Vermeiden Sie fest codierten Text auf Seiten und Komponenten; Verwenden Sie Ressourcen für Beschriftungen, Nachrichten, Titel, Breadcrumbs, Menüs und Bestätigungen.
• Überprüfen Sie die technischen Begriffe, um die Konsistenz zwischen Dokumentation, CLI-, API-Verträgen und Schnittstelle zu gewährleisten.
• Behalten Sie kulturübergreifend den gleichen Schlüsselsatz bei, um unerwartete Rückschläge oder teilweise übersetzte Bildschirme zu verhindern.
• Trennen Sie die wörtliche Übersetzung von der Produktanpassung: Wenn ein Begriff für den Endbenutzer lokalisiert werden muss, behalten Sie die funktionale Bedeutung der Aktion bei.

Auf generierten Seiten gibt es normalerweise Ressourcen auf Seiten-, Formular- und Rasterebene. Diese Trennung ermöglicht die Weiterentwicklung jedes Teils, ohne dass Auflistungs-, Bearbeitungs-, Validierungs- und Navigationstexte vermischt werden.

Reaktionsschnelles, sofort einsatzbereites CRUD

Das generierte CRUD beschleunigt die Bereitstellung, da es die sich wiederholende Grundlage des Bildschirms schafft: Auflistung, Formular, Integration mit API, Ressourcen, Paginierung, Filter, Aktionen und Code-Behind. Dennoch sollte es als Produkterlebnis und nicht nur als technisches Gerüst betrachtet werden.

Ein guter CRUD-Bildschirm muss es dem Benutzer ermöglichen, Datensätze zu finden, den aktuellen Status zu verstehen, sicher Maßnahmen zu ergreifen und Fehler zu beheben. Dies gilt sowohl für interne Backoffice-Bildschirme als auch für Portale, die sich an Kunden oder Partner richten.

• Wählen Sie Listenspalten aus, die bei der Entscheidungsfindung hilfreich sind. Vermeiden Sie Netze mit technischen Feldern, die dem Bediener nichts sagen.
• Konfigurieren Sie Filter und Paginierung entsprechend der erwarteten Datenmenge und den Hauptsuchkriterien des Benutzers.
• Überprüfen Sie die Validierungen und Fehlermeldungen, um das Problem in der Domänensprache und nicht nur in Bezug auf die Implementierung zu erklären.
• Stellen Sie die Zustände „Leer“, „Laden“ und „Absturz“ sicher, um stille Bildschirme zu vermeiden, wenn keine Daten vorhanden sind, API Zeit benötigt oder ein Vorgang nicht abgeschlossen wird.
• Bestätigen Sie unwiderrufliche Löschungen und Vorgänge und machen Sie deutlich, welcher Datensatz betroffen ist.
• Zeigen Sie mit lokalisierten Benachrichtigungen und Nachrichten klares Feedback nach dem Speichern, Bearbeiten, Löschen oder Fehlschlagen.
• Schützen Sie Aktionen durch Berechtigungen im Backend und Frontend. Das Ausblenden von Schaltflächen verbessert das Erlebnis, ersetzt jedoch nicht die tatsächliche Autorisierung.
• Überprüfen Sie die Reaktionsfähigkeit auf kleineren Bildschirmen, insbesondere bei Aktionsmenüs, Filtern, Pflichtfeldern und Rastern mit vielen Spalten.

Der von Lino generierte Ausgangspunkt muss als kohärente und integrierte Basis behandelt werden. Von dort aus passt das Team die visuelle Dichte, die Feldreihenfolge, die Anzeigeregeln, Berechtigungen und Texte an, um den tatsächlichen Produktprozess widerzuspiegeln.