Une ventilation des types de projets Blazor

Nous discutons des trois types de projets disponibles avec Blazor 0.5.1, comprenons les scénarios auxquels ils doivent être appliqués et explorent les attentes de chacun.

Blazor est une application Web à page unique ( Framework SPA) construit sur .NET qui s'exécute dans le navigateur avec le runtime WebAssembly de Mono, ou côté serveur via SignalR. Blazor comprend une architecture de composants, un routage, un DOM virtuel et une API d'interopérabilité JavaScript. Actuellement, Blazor est dans un état expérimental qui permet un développement rapide, des itérations et, implicitement, des expériences .

Blazor a livré 0,1 en mars 2018 et quelques mois plus tard 0,5.1. Dans l'histoire courte de Blazor, qui dure environ six mois, il a déjà lancé une variété de types de projets pour les développeurs embarqués ayant des besoins d'applications variés. Dans cet article, discutez bien des trois types de projets disponibles à partir de la version 0.5.1, nous comprendrons quels scénarios appliquer et à quoi s’attendre de chacun. Nous allons intervenir et évaluer le côté serveur, le côté client et la pile complète. Si vous pensez avoir tout vu, assurez-vous de jeter un coup d'œil au type de projet Server-Side, qui peut s'avérer très différent de ce que l'on pourrait attendre.

Juste pour que nous commencions tous à travailler sur la même page,

Before You Blaze

Blazor est un framework Web expérimental non supporté qui ne devrait pas être utilisé pour les charges de travail de production en ce moment.

Au moment de l'écriture, Blazor est expédié au rythme d'une fois tous les ans. deux mois. En raison de la nature du projet, de nouveaux outils doivent être installés avant que les modèles de projet Blazor ne soient disponibles dans Visual Studio. La même chose s'applique à l'interface de ligne de commande (CLI) dotnet .

Installation

Si vous êtes le type de développeur qui passe la majorité de son temps dans Visual Studio, vous avez de la chance , Visual Studio est susceptible de fournir la meilleure expérience lorsque Blazor en est à ses balbutiements, cependant, l'interface CLI dotnet est toujours très pratique.

La configuration de Visual Studio nécessite les étapes suivantes:

1. Installez le .NET Core 2.1 SDK (2.1.300 ou version ultérieure)
2. Installation de Visual Studio 2017 (15.7 ou version ultérieure) avec la charge de travail ASP.NET et développement Web sélectionnée [19659012] Installez la dernière extension Blazor Language Services à partir de Visual Studio Marketplace

Ce processus d'installation ajoutera les trois types de projets que nous allons couvrir ci-dessous. Le projet de bibliothèque de composants Blazor, le quatrième et dernier type de projet, est uniquement disponible à partir de la CLI. La bibliothèque de composants Blazor n'entre pas dans le cadre de cet article car ce n'est pas un type de projet exécutable.

Pour rendre les modèles disponibles à partir de l'interface de ligne de commande dotnet ouvrez une console et exécutez la commande suivante:

 dotnet new -i Microsoft.AspNetCore.Blazor.Templates 

"Définir les Blazors pour fonctionner"

Avec les outils installés, nous sommes prêts à exécuter et à explorer les projets Blazor. La boîte de dialogue Nouvelle application Web ASP.NET Core contient les nouveaux types de projet.

Pour révéler la boîte de dialogue:

1. Sélectionnez Fichier> Nouveau projet> Web> Application Web ASP.NET Core [19659012] Assurez-vous que .NET Core et ASP.NET Core 2.1 (ou version ultérieure) sont sélectionnés en haut
2. Choisissez le modèle Blazor et sélectionnez OK

les types de projets de gauche à droite:

1. Blazor * Côté client
2. Blazor (ASP.NET Core hébergé) * Full-Stack
3. Blazor (Server- Side in ASP.NET Core) * Côté serveur

* Indique une brève description non officielle

Maintenant que nous avons trouvé chaque modèle de projet, nous pouvons discuter des détails

Blazor Client-Side

Le modèle côté client Blazor peut être comparé à une application HTML, CSS et JavaScript, similaire à d'autres frameworks SPA. Cependant, dans le cas de Blazor, JavaScript est complété par .NET et C # via WebAssembly. Contrairement aux projets ASP.NET MVC qui utilisent Razor, Blazor (côté client) n'est pas rendu sur le serveur, au lieu de cela, le HTML est livré au navigateur via la structure Blazor sur le client. Donc, essentiellement, le navigateur traite tout ce qui est dans ce projet est une ressource statique.

Le projet pouvant être traité comme un ensemble de ressources statiques, il offre des possibilités intéressantes qui restent à voir dans l'écosystème ASP.NET. Les projets construits avec ce modèle peuvent être hébergés sur pratiquement toutes les ressources pouvant servir des fichiers statiques, par exemple: Pages GitHub et Azure Storage: hébergement de site Web statique .

de la façon de commencer avec Blazor ainsi que des mises en page de base, des contrôles de navigation et des styles depuis Bootstrap . La structure du projet est assez simple avec juste les quelques ressources décrites ci-dessous:

• / wwwroot : ressources statiques standard Web incluant: CSS, JavaScript, JSON, images et HTML
• / Pages : Razor ( .cshtml ) pages / fonctionnalités de l'application
• / _ Shared : composants communs ( .cshtml ) & mises en page
• App .cshtml : un fichier temporaire à supprimer dans les versions ultérieures de Blazor
• Program.cs et Startup.cs : amorçage et configuration de l'application

Au début certains concepts familiers peuvent apparaître lorsque Blazor utilise une approche similaire aux applications ASP.NET. Non seulement Program.cs et Startup.cs constituent une fonctionnalité courante dans les applications .NET, mais Blazor utilise également un concept similaire aux pages ASP.NET Core Razor. Les pages ou fonctionnalités de l'application Blazor se trouvent sous le chemin du projet Pages tandis que le routage est géré par la directive @page de la page. Dans la structure Blazor, une vue ou .cshtml est traitée comme un composant Web, y compris ceux marqués avec la directive @page .

 @page "/ myRoute"



@les fonctions {
  // logique de composant
} 

Toutes les pages d'exemple de Index Counter et Fetch Data sont incluses dans tous les projets Blazor. Ces éléments sont cohérents dans tous les types de projet, à l'exception de Fetch Data, car La principale différence entre chaque type de projet réside dans le fait que l'application est hébergée par rapport aux données qu'elle consomme . Compteur page et son balisage et sa logique de composant.

Counter

La page Counter est un composant simple décoré avec la directive page. Ce composant présente la composition de base d'un composant Blazor, notamment: routage, liaison de données et liaison / gestion d'événements.

Le composant counter utilise un bouton HTML de base pour incrémenter un champ de compteur étiquette de paragraphe. Parce que Blazor fonctionne comme une seule page, toutes les interactions du composant se produisent sur le client. Les mises à jour du modèle DOM (Document Object Model) du navigateur sont gérées par la structure de Blazor par liaison de données.

Passons à la page Fetch Data, nous verrons comment Blazor est capable de gérer des sources de données locales.

Fetch Data

Dans ce type de projet, la page Fetch Data est un composant qui utilise les données d'un fichier statique local. Le composant Fetch Data présente des concepts d'injection de dépendance et de modèle de base Razor. Cette version de Fetch Data est très similaire à l'exemple trouvé dans le modèle Full-Stack, à l'exception de l'emplacement dans lequel les données sont chargées.

En haut du composant suite à la directive de routage, l'injection de dépendance est déclarée. La directive @inject demande à Blazor de résoudre et d'instituer HttpClient sur la variable Http . Le HttpClient est ensuite utilisé par la logique des composants pour extraire des données à l'aide de GetJsonAsync qui lie les données de la requête JSON à un tableau d'objets WeatherForecast :

 @ page "/ fetchdata"
@inject HttpClient Http

// ... balisage omis pour des raisons de concision

@les fonctions {
  WeatherForecast [] prévisions;

  ignorer asynchrone Task Task OnInitAsync ()
  {
    forecast = attendre Http.GetJsonAsync  ("sample-data / weather.json");
  }

  // ...
} 

L'affichage des données WeatherForecast se fait en itérant la collection de prévisions et en liant les valeurs à une table HTML:

 @if (forecast == null)
{
  
 Chargement ... 
}
autre
{
   ... 
       @foreach (var prévision dans les prévisions)
      {
        
      }
    

    

    

          
 @ forecast.Date.ToShortDateString () 
          
 @ forecast.TemperatureC 
          
 @ forecast.TemperatureF 
          
 @ forecast.Summary 
        
  
} 

Aucun serveur n'est utilisé ou nécessaire pour ces exemples de base. Si nous prévoyons de développer notre application avec l'hébergement et les services Web, les modèles Full-Stack ou Server-Side peuvent constituer un meilleur point de départ.

Blazor Full-Stack

Le modèle Blazor Full-Stack englobe la même structure de projet comme modèle côté client avec quelques ajouts. Tout comme le modèle côté client, le serveur ne génère aucun code HTML et tous les fichiers sont livrés au client sous forme de fichiers statiques, y compris des fichiers binaires .NET. La différence est cependant ajoutée à l’hébergement et à l’API Web ASP.NET Core et à un projet partagé pour une logique d’application commune.

Le modèle comprend trois projets: une application client côté client Blazor.Client un ASP. Application serveur NET Core Blazor.Server et un projet .NET Standard partagé pour la logique applicative commune Blazor.Shared .

Blazor.Server

L'application serveur est responsable de servir l'application et fournir des endpionts API Web pour les données. Dans Startup.cs nous trouvons les paramètres MimeType qui configurent le serveur pour autoriser les fichiers *. Wasm et *. Dll à être servi. En outre, la compression est activée pour réduire la taille des fichiers binaires à mesure qu'ils sont transférés vers le client. La compression est activée via le middleware AddResponseCompression .

 services.AddResponseCompression (options =>
{
  options.MimeTypes = ResponseCompressionDefaults.MimeTypes.Concat (nouveau []
  {
    MediaTypeNames.Application.Octet,
    WasmMediaTypeNames.Application.Wasm,
  })
}); 

Le processus de démarrage est également celui où le middleware d'application Blazor est initialisé par app.UseBlazor . Cela identifie l'application Blazor.Client en cours de traitement.

 public void Configure (application IApplicationBuilder, IHostingEnvironment env)
{
  app.UseResponseCompression ();
  // ...
  app.UseBlazor  ();
} 

L'application est fournie avec un exemple simple de contrôleur d'API Web et d'action. Dans le SampleDataController une action WeatherForecasts génère un ensemble aléatoire de prévisions météorologiques. Dans le modèle Full-Stack, l'API Web WeatherForecasts remplace le fichier static weather.json situé dans le modèle côté client.

 publicData SampleDataController: Controller
{
  // ...

  [HttpGet("[action] ")]
  public IEnumerable  WeatherForecasts ()
  {
    // ...
  }
} 

Blazor.Client

Presque toute l'application cliente est identique à celle du modèle côté client. Toutefois, dans l'exemple FetchData diffère légèrement en demandant des données à partir du point de terminaison de l'API Web WeatherForcasts dans l'appel de la méthode GetJsonAsync.

 @functions {
  WeatherForecast [] prévisions;

  ignorer asynchrone Task Task OnInitAsync ()
  {
    forecast = attendre Http.GetJsonAsync  ("api / SampleData / WeatherForecasts");
  }
} 

Blazor.Shared

Étant donné que le projet inclut une solution serveur et client utilisant toutes les deux .NET, il est possible de partager du code entre les deux applications. Ceci est un scénario unique à Blazor puisque le client exécute le côté client .NET au lieu de JavaScript. L'exemple donné dans le modèle de projet utilise la même classe WeatherForecast sur le serveur et l'application cliente.

 class public WeatherForecast
{
  public DateTime Date {get; ensemble; }
  public int TemperatureC {get; ensemble; }
  chaîne publique Résumé {get; ensemble; }
  public int TemperatureF => 32 + (int) (TemperatureC / 0,5556);
} 

La classe WeatherForcast n'est qu'une idée de base du code partagé. Cependant, d'autres codes d'application partagés peuvent inclure: la validation, les convertisseurs et la logique métier découplée des concepts système, IO ou Web. En développant cette idée, une application théorique peut partager des bibliothèques entre d'autres structures .NET telles que: Xamarin, Windows Universal Platform (UWP) ou d'autres applications Web basées sur .NET.

Aucune compilation avant terme (AOT) [19659009] Dans d'autres technologies Web .NET telles que ASP.NET MVC (et Core MVC), les modèles Razor sont rendus par le serveur et envoyés au client sous forme de code HTML. Certains frameworks JavaScript tels qu'Angular et React partagent des responsabilités de rendu sur le client et le serveur dans un processus appelé Compilation AOT ou Isomorphic Rendering. Même si l'application client Blazor est hébergée sur un serveur .NET, toutes les vues sont rendues côté client dans les modèles de projet côté client et complet. Actuellement, il n'existe aucune option de rendu AOM / Isomorphic pour Blazor, mais un modèle d'application Blazor côté serveur existe.

Blazor Server-Side (aka Razor Components)

Le 12 septembre, lors de DotNetConf Blazor Server-Side a été annoncé comme une nouvelle fonctionnalité dans ASP.NET Core 3.0 et sera connu sous le nom de ASP.NET Razor Components .

ASP.NET 3.0 Razor Components sera le premier officiel (non

Le modèle de projet Blazor Server-Side adopte une approche très différente de la manière dont une application Blazor est livrée et interagit avec le navigateur. Lors de l'utilisation de la configuration côté serveur, Blazor utilise le navigateur en tant que "client léger" en déployant une application JavaScript SignalR sur le client. Sur le serveur, Blazor implémente un hub SignalR communiquant avec le client via des sockets Web. Dans le modèle d'hébergement côté serveur, Blazor est exécuté sur le serveur depuis une application ASP.NET Core. Les mises à jour de l'interface utilisateur, la gestion des événements et les appels JavaScript sont traités via la connexion SignalR. Dans cette configuration, il y a pas besoin de WebAssembly et Blazor est exécuté sur le runtime ASP.NET Core sur le serveur. Toutes les mises à jour de l'interface utilisateur sont envoyées sous forme de diff, de manière bidirectionnelle sous forme de paquets binaires sur des sockets Web. Pour l'utilisateur, l'application ne peut pas être distinguée de toute autre application Web.

Malgré les différences drastiques dans la manière dont Blazor fonctionne côté serveur, le modèle d'application réel reste relativement identique. Dans le modèle de projet côté serveur, il existe seulement quelques différences entre les exemples de code fournis par le modèle. Le modèle comprend deux projets: une application Server-Side Blazor App une application serveur ASP.NET Core Server qui héberge l'application Blazor.

App

The index.html est le point d’entrée client de l’application. Lorsqu'il est configuré pour une opération côté serveur Fichier JavaScript, blazor.server.js remplace blazor.webassembly.js . blazor.server.js appelle le client SignalR et établit la communication avec l'application côté serveur Blazor.

 ... 

   Chargement en cours ... 
   

Comme l'ensemble de l'application s'exécute côté serveur, dans ce type de projet, l'exemple Fetch Data utilise des données provenant d'un service local. La directive @inject dans cet exemple résout et l'instance de WeatherForecastService à la place de HttpClient comme indiqué dans le modèle de projet Full-Stack. Le WeatherForecastService dans l'exemple est une classe simple qui génère des données aléatoires. Cependant, dans un scénario réel, le service peut être un contexte, un référentiel ou d'autres sources de données de base de données Entity Framework. "/ fetchdata"
@inject WeatherForecastService ForecastService

// … balisage omis pour des raisons de concision

@les fonctions {
  WeatherForecast [] prévisions;

  ignorer asynchrone Task Task OnInitAsync ()
  {
    forecast = attendre ForecastService.GetForecastAsync (DateTime.Now);
  }

  // …
}

Le WeatherForecastService et d'autres services sont ajoutés au conteneur d'injection de dépendance dans la méthode ConfigureServices trouvée dans Startup.cs .

 public void ConfigureServices (Services IServiceCollection)
{
  // Puisque Blazor est exécuté sur le serveur, nous pouvons utiliser un service d'application
  // pour lire les données prévisionnelles.
  services.AddSingleton  ();
}

Server

Le projet de serveur fourni par le modèle est un simple hôte ASP.NET Core. Dans le Startup.cs de ce projet, le middleware UseServerSideBlazor est appelé et le démarrage de l'application Blazor est initialisé.

 public void Configure (application IApplicationBuilder, IHostingEnvironment env)
{
  app.UseResponseCompression ();

  // ...

  // Utilise les enregistrements de composants et les fichiers statiques du projet app.
  app.UseServerSideBlazor  ();
}

Avantages et inconvénients

Étant donné qu'une petite quantité de code JavaScript est requise pour amorcer le client et qu'aucun assemblage .NET n'est transféré au client, l'application Server-Side Blazor est efficace pour le trafic réseau. Même pendant le fonctionnement, le trafic réseau est léger car la communication entre le "client léger" du navigateur et le serveur est un petit paquet binaire. Cependant, les sockets Web étant utilisés, le client et le serveur doivent toujours être connectés. Cela signifie que les applications Blazor Server-Side ne peuvent pas fonctionner en mode hors connexion.

Conclusion

Bien que Blazor soit un nouveau cadre encore en phase expérimentale, il offre plusieurs possibilités de démarrage. Chaque type de projet inclut un ensemble similaire d'exemples avec les composants Counter et Fetch Data. L'exemple Fetch Data varie d'un projet à l'autre pour mettre en évidence les fonctionnalités spécifiques de ce type de projet.

Avec les modèles de projet Client-Side, Full-Stack et Server-side, les développeurs peuvent choisir le point de départ le mieux adapté aux exigences de leur application. Le modèle Sever-Side se concentre sur l’exécution complète des fichiers statiques dans le navigateur, tandis que le modèle Full-Stack inclut l’hébergement ASP.NET Core et l’API Web. L'utilisation du gabarit Sever-Side utilise la structure Blazor sur le serveur et s'appuie sur SignalR à la place de WebAssembly, ce qui permet de négocier des performances pour une connexion permanente.

Si vous êtes enthousiaste et prêt à expérimenter, laissez nous savons dans les commentaires ci-dessous. Quels sont vos projets pour Blazor?