Récapitulation du webinaire Blazor

Curieux d’adopter Blazor et comment cela fonctionne? Vous vous demandez si l'hébergement côté client ou côté serveur vous convient le mieux? Regardez notre récapitulatif de webinaire pour savoir ce que vous devez savoir.

Notre webinaire Telerik UI for Blazor a été très couvert et nous avons voulu partager un récapitulatif de l'événement. Si vous avez manqué le webinaire en direct ou si vous souhaitez le visionner à nouveau ou le partager avec un ami ou un collègue, vous pouvez trouver l'enregistrement ICI ou le visionner ici même.

Dans cet article, vous apprendrez Tout sur le framework et l'architecture Blazor et sur ce que nous pensons de Blazor va changer l'écosystème de développement ASP.NET.

Qu'est-ce que Blazor?

Pour commencer, Blazor est un tout nouveau framework de Microsoft qui vise à les développeurs à construire des applications SPA en utilisant les technologies .NET existantes. Et le framework Blazor a des fonctionnalités que vous verriez dans des frameworks populaires tels que Angular ou React, mais tout cela est réalisé avec .NET. Nous avons des fonctionnalités telles que le rendu côté serveur, les formulaires et la validation, le routage, le routage côté client, les tests unitaires et sont particulièrement importantes pour nous ici dans l'équipe Telerik, les packages de composants le tout prêt à l'emploi.

Examinons l'architecture de Blazor et en apprenons un peu plus sur la manière dont nous sommes capables d'écrire des applications .NET à pile complète qui s'exécutent sur le client. Blazor lui-même est indépendant de la manière dont l'application est hébergée. Et il existe actuellement deux façons d’héberger une application Blazor. Nous avons un modèle d'hébergement côté client et un modèle d'hébergement côté serveur. Et je vais m'étendre sur chacun de ces éléments et sur la manière dont ils sont mis en œuvre.

Il est important de noter que la version client de Blazor est exécutée sur WebAssembly qui sera publié. avec .NET 5 en mai 2020. Entre-temps, la partie de rendu côté serveur de Blazor est entièrement prise en charge depuis le lancement de .NET Core 3.

Modèle d'hébergement côté client

Tout d'abord, apprenons. comment fonctionne la version côté client de Blazor. Dans un navigateur classique, nous avons le moteur de navigateur qui prend en JavaScript, et il l'envoie via un analyseur. Ce JavaScript est ensuite compilé et transformé en code octet. Et une fois que notre application est chargée dans le navigateur, elle peut interagir avec le DOM et exécuter des API.

WebAssembly – Blazor côté client

Nous disposons d'une nouvelle technologie appelée WebAssembly. WebAssembly est un code d'octet que les navigateurs peuvent exécuter. Ce qui rend WebAssembly différent, c'est qu'il est analysé et compilé avant d'être livré au navigateur. Des langages autres que JavaScript, tels que C ++ et C #, peuvent être compilés directement en code octet et utilisés par le navigateur. C’est donc ce que Microsoft a fait: le runtime .NET a été compilé dans WebAssembly pour exécuter .NET dans le navigateur.

WebAssembly et le runtime .NET exécuté dans le navigateur permettent à Blazor d’exécuter client. côté. Lorsque Blazor s'exécute sur le client, cela nous permet d'utiliser des assemblys .NET et d'exécuter notre code d'application .NET dans le navigateur sans plug-in, car il utilise toutes les technologies standard Web. Les applications Blazor sont essentiellement des applications .NET qui s'exécutent sur le client.

Modèle d'hébergement côté serveur

Voyons maintenant la version côté serveur de Blazor et son implémentation sur le serveur. Contrairement à la version client de Blazor, Blazor côté serveur s'exécute sans WebAssembly. Tout votre code de votre application est hébergé sur le serveur et s'exécute sur votre serveur, se connecte au client et l'utilise comme client léger.

Modèle d'hébergement Blazor côté serveur

Une petite charge JavaScript est envoyée à votre navigateur. Il se connecte via SignalR et envoie des informations à votre application via WebSockets. Une fois la connexion établie, votre navigateur peut ensuite envoyer des événements et des mises à jour à l'application exécutée sur le serveur. Blazor détermine ensuite quels éléments doivent être modifiés sur votre écran et n'envoie que ces modifications au navigateur afin de les modifier dans le DOM.

Une des choses sympas de l'architecture côté client est le fait qu'elle peut être très verticale. tranche l'architecture. Il n'y a pas beaucoup de temps système car votre application est exécutée à un endroit où les données peuvent être stockées, ce qui vous permet d'écrire des applications extrêmement rapidement. Une application N-tier n’est pas nécessaire dans certains scénarios.

Comparaison côte à côte

Si nous examinons ces deux systèmes côte à côte, nous bénéficions de certains avantages de chaque modèle d’hébergement. Avec Blazor côté client, nous n’avons que peu ou pas de surcharge du serveur car tout est exécuté sur le framework .NET au sein du client dans leur navigateur. C'est une technologie RESTful, tout comme Angular, React ou une application Ajax. Et il est également capable de faire du travail hors ligne et du type PWA.

Certains des inconvénients de l'exécution sur le client incluent la taille plus grande de la charge utile, car nous envoyons du code au client. Et tout autant que RESTful peut être positif, c'est un environnement déconnecté, et nous devons en être conscients. Prise en charge de Blazor côté client pour le mois de mai 2020.

Nous avons seulement envoyé un fichier JavaScript et de petits paquets binaires contenant les mises à jour du navigateur. Il y a potentiellement moins d’abstraction, car il s’agit d’un environnement connecté. Le pré-rendu est pris en charge immédiatement. , idéal pour le référencement naturel et pris en charge aujourd'hui. Et avec le lancement de la prise en charge d'ASP.NET Core 3.0 par Microsoft, tout ce dont vous avez besoin pour Blazor côté serveur va de pair.

En ce qui concerne le côté serveur, certains des inconvénients potentiels qu'un constan t connexion est nécessaire pour que votre application fonctionne grâce à la technologie WebSocket et vous utilisez des ressources de serveur au lieu d’envoyer tout ce qui est traité au client.

J'espère que cela a servi de bon aperçu de haut niveau de la façon dont les deux hébergeurs les modèles se dressent.

Maintenant, il est important de noter que, même si nous pensons qu'il existe deux modèles d'hébergement ici, le code que vous écrivez pour les deux va être à peu près identique à 99%. La seule chose qui change entre une application cliente et une application serveur est la façon dont vous accédez à vos données. Tous les composants que vous écrivez et toute la logique de votre interface utilisateur seront identiques à 100% entre ces deux modèles.

Conditions préalables pour Blazor

En ce qui concerne les conditions préalables pour Blazor, vous aurez besoin du SDK Core .NET. Et à l'avenir pour Blazor côté client, vous aurez peut-être besoin de bits de prévisualisation mis à jour pour le SDK .NET. Même chose pour Visual Studio, vous aurez besoin de Visual Studio 2019. Pour les personnes souhaitant utiliser la version côté client de cette technologie, vous devez rester sur le canal de prévisualisation de Visual Studio car il reçoit des mises à jour constantes à partir d'ASP.NET. équipe. Pour le serveur Blazor côté serveur, vous devriez maîtriser .NET Core 3.0 dans Visual Studio 2019.

Enfin, s’agissant de notre interface utilisateur Telerik pour les composants Blazor nous constatons que nous N'utilisez pas de technologie client ou serveur, car ils fonctionnent dans les deux cas.

En savoir plus sur Blazor

Si vous souhaitez en savoir plus sur Blazor et sur la façon de commencer, Je vous suggère de consulter les ressources suivantes: