Blazor: Full stack C # et argumentaire de Microsoft pour les irréductibles ASP.NET Web Form

Microsoft présente son framework Blazor, le dernier ajout à la plate-forme ASP.NET Core, comme une mise à niveau appropriée pour les développeurs C # toujours attachés à Web Forms, le modèle de programmation datant de la première version du .NET Framework en 2002.

Les formulaires Web ont été conçus pour faciliter la transition vers les applications Web pour les développeurs de bureau. Il existe un concepteur visuel, une boîte à outils avec des contrôles tels que des boutons et des zones de liste, et les développeurs peuvent double-cliquer sur un contrôle et écrire du code C # qui s’exécute sur le serveur.

Le modèle sans état du Web est déguisé par un système de post-back et une variable ViewState masquée qui enregistre l’état des contrôles. La facilité d’utilisation apparente a été largement adoptée par les développeurs de la plate-forme Microsoft, mais le cadre a également des frustrations, étant difficile à intégrer avec les tests unitaires, vulnérable aux problèmes et aux bogues lorsque l’abstraction basée sur ViewState ne fonctionne pas comme prévu et n’est pas en phase avec des bibliothèques JavaScript modernes.

Malgré son âge, Microsoft a déclaré l’année dernière que «près d’un demi-million de développeurs Web utilisent les formulaires Web ASP.NET chaque mois».

C’est curieux à certains égards, car cela fait plus d’une décennie que Microsoft a publié ASP.NET MVC (2009), un framework Web destiné à résoudre les problèmes liés aux formulaires Web. ASP.NET MVC – où MVC signifie Model View Controller – possède des fichiers de contrôleur qui gèrent le routage et une certaine logique métier, ainsi qu’un moteur de visualisation qui rend les pages Web.

L’aspect modèle fait abstraction de la base de données, souvent à l’aide du mappage relationnel objet Entity Framework de Microsoft. ASP.NET MVC a une approche plus propre et se prête aux tests unitaires. Le moteur d’affichage d’origine utilisait des formulaires Web sans le système de publication, mais il a été rapidement remplacé par un nouveau moteur utilisant une syntaxe appelée Razor pour intégrer du contenu dynamique dans HTML et JavaScript.

Razor a résisté, bien qu’ASP.NET MVC ait cédé la place à Razor Pages, similaire mais avec une conception plus logique (et reconnaissant que l’aspect «MVC» n’a jamais été pur). Bien que ASP.NET MVC ou Razor Pages soit maintenant le choix courant, pourquoi tant de personnes sont-elles bloquées avec des formulaires Web? La réponse est peut-être qu’il est plus facile à apprendre et permet aux développeurs d’écrire tout leur code en C # ou Visual Basic; si l’objectif est une solution à un problème commercial, c’est souvent suffisant. Il existe des parallèles avec les frameworks de bureau de Microsoft, où Windows Presentation Framework a résolu de nombreux problèmes avec les anciens Windows Forms (mise à l’échelle, accélération graphique, conception riche), mais sa plus grande complexité signifiait que de nombreux développeurs ont refusé de changer.

Microsoft continue de prendre en charge les formulaires Web, mais la technologie est désormais figée et n’a pas été portée sur ASP.NET Core. Il est en grande partie uniquement Windows, bien que Mono multiplateforme ait un certain support).

Entrez Blazor

Entrez Blazor, le dernier framework d’application Web issu de l’équipe ASP.NET de Microsoft. Blazor est apparu sur la scène début 2018. Microsoft pense apparemment que cela pourrait être la chose qui attrape certains retards de Windows Forms et a fourni un livre électronique sur la façon de migrer, bien qu’il ait également déclaré que «la migration d’une base de code de ASP.NET Web Forms vers Blazor est une tâche qui prend du temps. »

Une application Blazor a le code dans un assemblage .NET standard mais l’interface utilisateur est HTML et CSS standard

Blazor ne ressemble pas beaucoup aux formulaires Web mais a certains points communs. La première est que les développeurs peuvent écrire C # partout, à la fois sur le serveur et pour le navigateur client. Microsoft appelle cela «full stack C #».

«Blazor partage de nombreux points communs avec les formulaires Web ASP.NET, comme avoir un modèle de composant réutilisable et un moyen simple de gérer les événements utilisateur», ont écrit les auteurs. Le framework Blazor se présente sous plusieurs formes. Le concept initial, et l’une des options, est Blazor WebAssembly (Wasm). Le runtime .NET est conforme à Wasm, l’application est compilée dans une DLL .NET et s’exécute dans le navigateur, complétée par l’interopérabilité JavaScript.

Jetez un œil à Blazor WebAssembly est facile. Installez le SDK – par exemple le nouveau .NET 5.0 chaud, prévu pour la semaine prochaine – et tapez:

dotnet new blazorwasm -o BlazorHello

Tapez ensuite:

dotnet watch run

pour exécuter l’exemple d’application. Il est instructif de regarder une version de version. Il y a BlazorHello.dll, un assemblage comme les autres.

Sous net5.0 wwwroot _framework, vous trouvez tous les assemblys gubbins: framework, le runtime appelé dotnet.wasm et la bibliothèque JavaScript blazor.webassembly.js qui assemble tout. Ce dossier est d’une taille alarmante: plus de 34 Mo dans notre cas. Ce n’est pas aussi grave qu’il y paraît puisque les fichiers existent à la fois non compressés et sous forme compressée .gz, et ils ne seront pas tous demandés. L’un qui est essentiel est le runtime, dotnetwasm.gz, qui fait un peu plus de 1 Mo, ou 2,7 Mo non compressé.

L’exemple d’application indique «Chargé 8,67 Mo de ressources. Cette application a été créée avec la fonction de liaison (tremblement d’arbre) désactivée. Les applications publiées seront beaucoup plus petites. »

Les fichiers d’exécution de Blazor sont extrêmement volumineux, mais la compression et l’élimination du code inutilisé réduisent la taille des applications publiées

Il est également à noter que le HTML livré au navigateur n’est guère plus qu’un élément div pour contenir l’application. Au moment de l’exécution, JavaScript le remplit avec les contrôles qui forment l’interface utilisateur. Ce sont des contrôles HTML standard, pas un élément de canevas de boîte noire.

Blazor est conçu pour les applications d’une seule page et rappelle Silverlight – le plugin de navigateur de Microsoft dans lequel exécutait du code .NET dans le navigateur – mais avec une interface utilisateur HTML / CSS.

Il existe deux autres modèles d’application Blazor. Blazor Server s’exécute sur le serveur et prend en charge un client de navigateur léger communiquant avec WebSockets (ASP.NET SignalR). Le modèle de programmation est le même, mais c’est une approche client léger qui signifie un chargement plus rapide et aucun WebAssembly n’est requis; il peut même être persuadé de fonctionner dans IE11.

Ensuite, il y a Mobile Blazor, récemment mis à jour vers Preview 5, qui utilise le modèle de programmation Blazor mais avec une interface utilisateur HTML ou des formulaires Xamarin (interface utilisateur native) pour s’exécuter en tant qu’application mobile.

Bien que les liaisons mobiles soient décrites comme expérimentales, il semble que Microsoft prenne le projet au sérieux. Le nouvel aperçu ajoute la prise en charge des graphiques SkiaSharp, des outils de reconnaissance de gestes, de la prise en charge du double écran, du DataPicker, du TimePicker, de la disposition simplifiée de la grille, etc.

Le modèle de programmation ressemble à un croisement entre les pages Razor et les formulaires Web. Il est plus facile que Razor Pages de démarrer, mais utilise la même syntaxe Razor. L’état est conservé dans le navigateur pendant une session; il s’agit d’une application d’une seule page, de sorte que les problèmes d’aller-retour dans les formulaires Web n’existent pas, à moins que l’utilisateur ne rafraîchisse la page de manière imprudente.

L’état de persistance entre les sessions se fait via la technologie Web standard, telle que l’interaction avec une base de données sur le serveur, mais avec une prise en charge intégrée du stockage du navigateur local pour permettre une utilisation hors ligne. Construire en tant que PWA (Progressive Web Application) est une option intégrée. Les développeurs peuvent également utiliser le système d’identité de Microsoft pour obtenir une assistance instantanée pour l’enregistrement, la connexion, l’authentification, etc. ou ils peuvent utiliser Azure Active Directory.

Un gros avantage pour la productivité est que le code peut être partagé entre le client et le serveur et fonctionne de la même manière. Les développeurs peuvent mettre en place un projet avec des classes partagées. Cela facilite le travail avec les mêmes objets métier sur le client et le serveur.

Les développeurs doivent noter qu’avec le modèle WebAsssembly, tout le code client se retrouve dans le navigateur et peut potentiellement être rétro-conçu. Cela signifie qu’il faut prendre soin d’éviter d’envoyer des secrets ou d’accéder à des API privilégiées jusqu’au navigateur. Il en va de même pour les applications JavaScript à page unique, mais les développeurs .NET habitués à exécuter leur code sur le serveur peuvent avoir besoin de repenser certaines approches de la sécurité.

Blazor dans .NET 5.0 est considérablement amélioré. Le gros problème est que «Blazor WebAssembly dans .NET 5 est deux à trois fois plus rapide pour la plupart des scénarios», selon les notes de publication. D’autres modifications incluent le CSS spécifique aux composants, la possibilité de définir le focus de l’interface utilisateur dans le code, le nouveau composant InputFile pour le téléchargement de fichiers, Microsoft Identity v 2.0, etc.

Quelle est la place de Blazor dans la gamme complexe de produits de développement de Microsoft? Ce n’est pas une percée pour les applications Web, car la livraison d’applications sous forme d’assemblages .NET présente des inconvénients et ce ne sera pas idéal pour les frameworks JavaScript modernes tels que React. L’interopérabilité entre WebAssembly et JavaScript fonctionne, mais est lente. De même, les développeurs déjà à l’aise avec ASP.NET MVC ou Razor Pages sont probablement heureux de continuer à exécuter JavaScript sur le client. Il y a cependant un point idéal pour les développeurs C # avec beaucoup de code .NET et d’expérience existants qui ont maintenant un chemin vers un cadre d’application Web multiplateforme qui devrait être aussi bon ou meilleur pour les applications rapides orientées métier que les formulaires Web.