- 12/01/2020
- 6 minutes pour lire
-
-
un -
s -
Y -
g -
P -
+1
-
« Atwood de la Loi: Toute application qui peut être écrit en JavaScript, finira par être écrit en JavaScript., »
– Jeff Atwood
Il existe aujourd’hui deux approches générales pour créer des applications web: les applications web traditionnelles qui exécutent la majeure partie de la logique d’application sur le serveur et les applications à page unique (SPAs) qui exécutent la majeure partie de la logique d’interface utilisateur dans un navigateur web, Une approche hybride est également possible, la plus simple étant d’héberger une ou plusieurs sous-applications riches de type SPA dans une application web traditionnelle plus grande.,
utilisez des applications web traditionnelles lorsque:
-
Les exigences côté client de votre application sont simples ou même en lecture seule.
-
votre application doit fonctionner dans les navigateurs sans prise en charge de JavaScript.
-
Votre équipe ne connaît pas les techniques de développement JavaScript ou TypeScript.
l’Utilisation d’un SPA lorsque:
-
Votre demande doit exposer une interface utilisateur riche, avec de nombreuses fonctionnalités.
-
Votre équipe est familiarisée avec le développement JavaScript, TypeScript ou Blazor WebAssembly.,
-
votre application doit déjà exposer une API pour d’autres clients (internes ou publics).
En outre, les cadres SPA nécessitent une plus grande expertise architecturale et de sécurité. Ils connaissent un taux de désabonnement plus élevé en raison de mises à jour fréquentes et de nouveaux frameworks que les applications web traditionnelles. La configuration des processus de construction et de déploiement automatisés et l’utilisation d’options de déploiement telles que les conteneurs peuvent être plus difficiles avec les applications SPA que les applications web traditionnelles.
Les améliorations de l’expérience utilisateur rendues possibles par L’approche SPA doivent être mises en balance avec ces considérations.,
Blazor
ASP.NET Core comprend un modèle de création d’interfaces utilisateur riches, interactives et composables appelé Blazor. Blazor côté serveur permet aux développeurs de créer une interface utilisateur avec C# et Razor sur le serveur et de connecter l’interface utilisateur de manière interactive au navigateur en temps réel à l’aide d’une connexion SignalR persistante. Blazor WebAssembly introduit une autre option pour les applications Blazor, leur permettant de s’exécuter dans le navigateur à l’aide de WebAssembly. Comme il S’agit d’un véritable.net exécuté sur WebAssembly, vous pouvez réutiliser du code et des bibliothèques à partir de parties côté serveur de votre application.,
Blazor fournit une nouvelle troisième option à prendre en compte lors de l’évaluation de la création d’une application web purement rendue par le serveur ou D’un SPA. Vous pouvez créer des comportements client riches et de type SPA à l’aide de Blazor, sans avoir besoin d’un développement JavaScript important. Les applications Blazor peuvent appeler des API pour demander des données ou effectuer des opérations côté serveur. Ils peuvent interopérer avec JavaScript si nécessaire pour tirer parti des bibliothèques et des frameworks JavaScript.,
envisagez de créer votre application Web avec Blazor lorsque:
-
votre application doit exposer une interface utilisateur riche
-
Votre équipe est plus à l’aise avec le développement.net que le développement JavaScript ou TypeScript
Si vous avez une application Web forms existante que vous envisagez de migrer vers. net Core ou le dernier. Net, vous pouvez consulter le livre électronique gratuit, Blazor for Web Forms Developers pour voir si il est logique d’envisager de le migrer vers blazor.
pour plus d’informations sur Blazor, voir Mise en route avec Blazor.,
quand choisir des applications web traditionnelles
la section suivante est une explication plus détaillée des raisons précédemment énoncées pour choisir des applications web traditionnelles.
votre application a des exigences simples, éventuellement en lecture seule, côté client
de nombreuses applications web sont principalement consommées en lecture seule par la grande majorité de leurs utilisateurs. Les applications en lecture seule (ou principalement en lecture) ont tendance à être beaucoup plus simples que les applications qui maintiennent et manipulent beaucoup d’États., Par exemple, un moteur de recherche peut être constitué d’un seul point d’entrée avec une zone de texte et une deuxième page pour afficher les résultats de la recherche. Les utilisateurs anonymes peuvent facilement faire des demandes, et il y a peu besoin de logique côté client. De même, l’application publique d’un blog ou d’un système de gestion de contenu consiste généralement principalement en du contenu avec peu de comportement côté client. De telles applications sont facilement construites comme des applications web traditionnelles basées sur un serveur, qui effectuent une logique sur le serveur web et rendent le code HTML à afficher dans le navigateur., Le fait que chaque page unique du site ait sa propre URL qui peut être mise en signet et indexée par les moteurs de recherche (par défaut, sans avoir à ajouter cette fonctionnalité en tant que fonctionnalité distincte de l’application) est également un avantage évident dans de tels scénarios.
votre application doit fonctionner dans des navigateurs sans prise en charge JavaScript
Les applications Web qui doivent fonctionner dans des navigateurs avec une prise en charge JavaScript limitée ou inexistante doivent être écrites à l’aide de workflows d’applications web traditionnels (ou au moins être en mesure de revenir à un tel comportement)., Les SPAs nécessitent JavaScript côté client pour fonctionner; s’il n’est pas disponible, les SPAs ne sont pas un bon choix.
Votre équipe ne connaît pas les techniques de développement JavaScript ou TypeScript
Si votre équipe ne connaît pas JavaScript ou TypeScript, mais est familière avec le développement d’applications Web côté serveur, alors ils seront probablement en mesure de fournir une application web traditionnelle plus rapidement qu’un SPA., À moins que l’apprentissage de la programmation des SPAs ne soit un objectif ou que l’expérience utilisateur offerte par un SPA ne soit requise, les applications web traditionnelles constituent un choix plus productif pour les équipes qui connaissent déjà leur création.
quand choisir des SPAs
la section suivante est une explication plus détaillée du moment où choisir un style de développement D’Applications à une seule Page pour votre application web.,
votre application doit exposer une interface utilisateur riche avec de nombreuses fonctionnalités
Les SPAs peuvent prendre en charge des fonctionnalités client riches qui ne nécessitent pas de recharger la page lorsque les utilisateurs effectuent des actions ou naviguent entre les zones de l’application. Les SPAs peuvent se charger plus rapidement, récupérer des données en arrière-plan, et les actions individuelles des utilisateurs sont plus réactives car les rechargements de pleine page sont rares. Les SPAs peuvent prendre en charge les mises à jour incrémentielles, en enregistrant des formulaires ou des documents partiellement remplis sans que l’utilisateur ait à cliquer sur un bouton pour soumettre un formulaire., Les SPAs peuvent prendre en charge des comportements client riches, tels que le glisser-déposer, beaucoup plus facilement que les applications traditionnelles. Les SPAs peuvent être conçus pour fonctionner en mode déconnecté, en effectuant des mises à jour d’un modèle côté client qui sont finalement synchronisées sur le serveur une fois la connexion rétablie. Choisissez une application de style SPA si les exigences de votre application incluent des fonctionnalités riches qui vont au-delà de ce que les formulaires HTML typiques offrent.,
fréquemment, les SPAs doivent implémenter des fonctionnalités intégrées aux applications web traditionnelles, telles que l’affichage d’une URL significative dans la barre d’adresse reflétant l’opération en cours (et permettant aux utilisateurs de mettre en signet ou de créer un lien profond vers cette URL pour y revenir). Les SPAs devraient également permettre aux utilisateurs d’utiliser les boutons Précédent et suivant du navigateur avec des résultats qui ne les surprendront pas.
Votre équipe est familiarisée avec le développement JavaScript et/ou TypeScript
L’écriture de SPAs nécessite une connaissance des techniques et bibliothèques de programmation JavaScript et / ou TypeScript et côté client., Votre équipe doit être compétente pour écrire du JavaScript moderne en utilisant un framework SPA comme Angular.
votre application doit déjà exposer une API pour d’autres clients (internes ou publics)
Si vous prenez déjà en charge une API web à utiliser par d’autres clients, cela peut nécessiter moins d’efforts pour créer une implémentation SPA qui exploite ces API plutôt que de reproduire la logique sous forme côté serveur. Les SPAs utilisent largement les API web pour interroger et mettre à jour les données lorsque les utilisateurs interagissent avec l’application.,
Quand choisir Blazor
La section qui suit est une explication plus détaillée de quand choisir Blazor pour votre application web.
votre application doit exposer une interface utilisateur riche
comme les SPAs basés sur JavaScript, les applications Blazor peuvent prendre en charge un comportement client riche sans rechargement de page. Ces applications sont plus réactives pour les utilisateurs, récupérant uniquement les données (ou HTML) nécessaires pour répondre à une interaction utilisateur Donnée. Conçues correctement, les applications Blazor côté serveur peuvent être configurées pour s’exécuter en tant qu’applications Blazor côté client avec un minimum de modifications une fois cette fonctionnalité prise en charge.,
Votre équipe est plus à l’aise avec le développement.net que le développement JavaScript ou TypeScript
de nombreux développeurs sont plus productifs avec. net et Razor qu’avec des langages côté client comme JavaScript ou TypeScript. Étant donné que le côté serveur de L’application est déjà en cours de développement avec.net, L’utilisation de Blazor garantit que chaque développeur. net de l’équipe peut comprendre et potentiellement créer le comportement du frontal de l’application.,
tableau de décision
le tableau de décision suivant résume certains des facteurs de base à prendre en compte lors du choix entre une application web traditionnelle, un SPA ou une application Blazor.,