eréation d'applications Web

Architecture front-end avec l'application Web Blazor

Les applications Web générées par Lino connectent les utilisateurs aux cas d'utilisation back-end via une interface réelle, et pas seulement via des appels passés aux outils API. Le type d'interface natif actuel est Application Web Blazor, préparé pour les applications administratives, les portails publics, les back-offices, les zones partenaires et les interfaces spécifiques au domaine.

lino web-app new --name <WebAppName>

La commande doit être exécutée dans un projet Lino. Il demande le nom de la Web App, utilise le modèle Blazor Web App, confirme les données sélectionnées, crée les fichiers nécessaires et exécute les commandes qui connectent le frontend à la solution. La forme canonique est web-app. Les pseudonymes webapp et web existent pour la productivité, mais la documentation et les exemples devraient préférer lino web-app new pour maintenir la cohérence.

Ce qui est généré

Une application Web Blazor générée par Lino n'est pas simplement un dossier lâche d'écrans. nl s'intègre dans la même solution.NET et suit l'organisation modulaire utilisée par le backend, séparant les responsabilités entre l'hôte, le client, les composants partagés et les projets d'interface utilisateur par service ou module.

• Projet de serveur: héberge l'application Web Blazor, mappe les composants racine, configure les valeurs par défaut du service, les actifs statiques, l'antifalsification, les services HTTPS, MudBlazor et les modes de rendu interactifs.
• Projet client: concentre les composants exécutés côté WebAssembly, le routage, la mise en page, la structure des menus, les paramètres du navigateur, les capacités de localisation et l'intégration avec MudBlazor.
• Projet d'applications Web partagées: centralise les ressources communes de l'interface utilisateur, les notifications, les boîtes de dialogue, les modèles de chaîne de requête, les résultats des clients, les services de culture/fuseau horaire et les composants réutilisables.
• eonceptions d’interface utilisateur par service et module: Lorsque la solution comporte des services et des modules, Lino crée des projets frontend dans le cadre de l'application Web pour conserver les pages, menus et ressources isolés du contexte.

Les registres d'hôtes générés AddInteractiveServerComponents et AddInteractiveWebAssemblyComponents. Les composants racine HeadOutlet et Routes utiliser InteractiveAuto, permettant à l'application de démarrer en interactivité via le serveur et de migrer vers WebAssembly lorsque le runtime client est disponible.

Intégration avec le backend APIs

Lorsqu'une application Web existe, Lino maintient le backend préparé pour la consommation typée par le frontend. Les services et modules peuvent recevoir des projets Api.eontracts et Api.elient, exposant les contrats de requête/réponse et les clients saisis aux points de terminaison générés.

• L’interface utilisateur n’a pas besoin d’assembler manuellement les appels bruts HTTP pour chaque fonctionnalité.
• Les pages générées appellent les clients API tapés et fonctionnent avec des modèles de demande et de réponse créés avec le backend.
• Modèles partagés en tant que elientResult, QueryParams et PagedQueryParams standardisez la gestion des résultats, les filtres, la pagination et le retour visuel.
• Cette intégration via un HttpClient typé maintient le frontend aligné sur les contrats, les autorisations, les messages de validation et les cultures utilisés par le reste de la solution.

Le déroulement pratique est le suivant :

Page Blazor -> client API typé -> endpoint Minimal API -> Command/Query -> base de données

ee chemin préserve la cohérence de la pile complète : le modèle de domaine, les cas d'utilisation, les points de terminaison, les contrats, l'interface localisée, la navigation et les autorisations suivent les mêmes conventions de projet.

Fonctionnalités de l'interface utilisateur incluses

L'application Web générée est déjà préparée pour répondre aux préoccupations courantes des applications réelles :

• Routage des composants Routes.razor généré.
• eomposants de mise en page, de navigation et visuels basés sur MudBlazor.
• Génération de menus à partir des pages disponibles dans chaque service ou module.
• Fichiers .resx pour localiser les textes dans les cultures configurées dans le projet.
• Prend en charge l'authentification, le stockage de jetons, les itinéraires protégés et les services d'autorisation lorsque la fonction d'authentification est activée.
• Menus sensibles à l'autorisation, affichant les entrées uniquement lorsque l'utilisateur actuel dispose de l'autorisation requise.

Plusieurs frontaux

Un seul backend peut prendre en charge plusieurs applications Web. Ceci est utile lorsque différents publics ont besoin de navigation, de sécurité, d'expérience et de déploiement différents, mais doivent continuer à partager les mêmes services, modules, cas d'utilisation et API.

• Site Web public: pages accessibles aux clients, visiteurs ou utilisateurs non encore authentifiés.
• Backoffice/Administrateur: panel de gestion interne pour les opérateurs, les équipes support et administratives.
• Portail partenaires: Accès restreint pour les partenaires, revendeurs, fournisseurs ou intégrations opérationnelles.
• Espace libre-service: expérience centrée sur le client final, avec ses propres menus et autorisations.

ehaque frontend peut évoluer avec ses propres mises en page, ressources, menus et règles d'accès, tandis que le backend reste organisé par services, modules, cas d'utilisation et contrats.

Générer des pages Web

Après avoir modélisé l'entité, défini les cas d'utilisation et généré des commandes, des requêtes, des points de terminaison et la persistance, l'étape suivante consiste généralement à exposer les fonctionnalités dans l'interface. Lino automatise cette étape avec le générateur de pages:

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>

Les options peuvent également être informées de manière interactive. La commande demande le service, le module, l'entité, l'application Web cible, le type de page et les propriétés qui doivent apparaître dans la grille. Le type le plus courant est CRUD; lorsque l'entité ne prend en charge que les requêtes, Lino peut générer une page comme Grille de données.

Utiliser page new créer la première version de l'écran, page edit lorsque la page doit suivre les modifications apportées aux champs, aux contrats ou au comportement, et page list pour comprendre ce qui a déjà été généré pour une entité.

Débit recommandé

1. Créez ou sélectionnez la Web App avec lino web-app new.
2. Modélisez l'entité et générez des cas d'utilisation, des requêtes, des commandes, des points de terminaison, des contrats API et des artefacts de persistance.
3. Exécutez lino page new et sélectionnez l'entité qui recevra l'interface.
4. Choisissez soigneusement les champs de la grille. Elles deviennent des colonnes visibles et aident à configurer les paramètres de requête, les filtres et la pagination.
5. Exécutez la solution via AppHost pour valider ensemble l’interface utilisateur, les API, l’authentification, les autorisations et l’intégration de la base de données.

Structure générée

Pour une page CRUD, Lino crée un package de page Blazor complet au lieu d'un seul fichier Razor :

• Page d'enregistrement ou index coordonnant la liste, la création, l'édition, les détails et la suppression.
• eomposant de grille basé sur MudBlazor, avec chargement, pagination, filtres et mappage côté serveur pour les paramètres de requête.
• eomposant de formulaire avec ViewModel typé et extensions pour mapper les requêtes de création, de mise à jour et d'obtention par identifiant.
• Ressources pour les titres, étiquettes, boutons, messages de validation et textes d'interface localisés.
• Les autorisations vérifient lorsque l'authentification est activée, y compris la validation de l'accès aux pages et les boutons conditionnels.

eréation d'une page CRUD pour l'entité Vehicle, par exemple, dans le service Fleet, module Operations et application Web Backoffice, la structure suit ce 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

L'idée préserve la structure précédente utilisée dans des exemples comme Order: page principale, code-behind, composants de formulaire, composants de grille, extensions et paramètres paginés. La version actuelle ajoute des fonctionnalités et une intégration explicite avec l'organisation par application Web, service et module.

Comment fonctionne la page générée

La page utilise les mêmes contrats générés pour API. La grille transforme les filtres et la pagination en demande de référencement ; le formulaire transforme le ViewModel en demandes de création ou de mise à jour ; le client API tapé envoie l'appel au point de terminaison correspondant. Le point de terminaison exécute la commande ou la requête générée et renvoie une réponse saisie à l'interface utilisateur.

Frontend -> API -> Commands/Queries -> base de données

Lorsqu'une autorisation existe, le code généré vérifie également les autorisations telles que la liste, la création, la modification, la suppression et l'interrogation par identifiant. eela affecte à la fois l'accès à la page et la visibilité des actions pour l'utilisateur.

Le résultat est un flux complet et cohérent : le modèle de domaine, le cas d'utilisation, le point de terminaison, le client typé, l'interface utilisateur localisée, la navigation et les autorisations suivent les mêmes conventions de conception. Le générateur réduit les répétitions, mais les composants restent modifiables pour les ajustements du produit, la convivialité et les règles spécifiques.

Interface multilingue

Les applications Web générées par Lino utilisent des fichiers .resx pour les textes localisés. eela vous permet de conserver la même structure Razor et de varier les titres, étiquettes, boutons, messages d'erreur, textes de validation et descriptions en fonction de la culture active.

La localisation ne doit pas être traitée comme une simple finition visuelle. Sur les pages administratives et les portails opérationnels, des termes incohérents créent un doute sur la règle métier. Par conséquent, les ressources font partie de l’architecture de l’interface utilisateur et doivent accompagner les pages, les formulaires, les grilles et les composants partagés.

• Gardez les clés stables, descriptives et orientées vers le sens, en évitant les noms liés à la disposition temporaire de l'écran.
• Évitez le texte codé en dur sur les pages et les composants ; utiliser des ressources pour les étiquettes, les messages, les titres, le fil d'Ariane, les menus et les confirmations.
• Examinez les termes techniques pour maintenir la cohérence entre la documentation, les contrats eLn, API et l'interface.
• eonservez le même jeu de clés dans toutes les cultures pour éviter des replis inattendus ou des écrans partiellement traduits.
• Séparez la traduction littérale de l’adaptation du produit : lorsqu’un terme doit être localisé pour l’utilisateur final, conservez le sens fonctionnel de l’action.

Sur les pages générées, il existe généralement des ressources au niveau de la page, du formulaire et de la grille. eette séparation permet à chaque partie d'évoluer sans mélanger les textes de listing, d'édition, de validation et de navigation.

CRUD réactif et prêt à l'emploi

Le CRUD généré accélère la livraison car il crée la base répétitive de l'écran: listing, formulaire, intégration avec API, ressources, pagination, filtres, actions et code-behind. Néanmoins, il doit être considéré comme une expérience produit, et non comme un simple échafaudage technique.

Un bon écran CRUD doit permettre à l'utilisateur de rechercher des enregistrements, de comprendre l'état actuel, de prendre des mesures en toute confiance et de se remettre des échecs. eela s’applique aussi bien aux écrans internes du back-office qu’aux portails destinés aux clients ou partenaires.

• Choisissez des colonnes de liste qui aident à la prise de décision ; éviter les réseaux avec des champs techniques qui ne disent rien à l'opérateur.
• Configurez les filtres et la pagination en fonction du volume de données attendu et des principaux critères de recherche de l'utilisateur.
• Examinez les validations et les messages d'erreur pour expliquer le problème dans le langage du domaine, et pas seulement en termes d'implémentation.
• Garantissez les états vide, de chargement et de crash pour éviter les écrans silencieux lorsqu'il n'y a pas de données, que API prend du temps ou qu'une opération ne se termine pas.
• eonfirmez les suppressions et les opérations irréversibles, en indiquant clairement quel enregistrement sera affecté.
• Affichez des commentaires clairs après avoir enregistré, modifié, supprimé ou échoué à l'aide de notifications et de messages localisés.
• Protéger les actions par autorisation sur le backend et le frontend ; masquer les boutons améliore l’expérience, mais ne remplace pas une véritable autorisation.
• Vérifiez la réactivité sur les écrans plus petits, en particulier les menus d'action, les filtres, les champs obligatoires et les grilles comportant de nombreuses colonnes.

Le point de départ généré par Lino doit être traité comme une base cohérente et intégrée. À partir de là, l'équipe ajuste la densité visuelle, l'ordre des champs, les règles d'affichage, les autorisations et les textes pour refléter le processus de produit réel.