Je pense que chaque développeur, quand il est arrivé à un nouveau projet, a pensé qu'il serait bien de remonter le temps et de dire aux pères de votre projet que les modèles devraient non seulement être demandés lors de l'entretien, mais également appliqués au vrai projet, mais sérieusement.
En particulier, c'est probablement un modèle, mais une très bonne règle est que le balisage doit être séparé du code. Cela s'applique aux bons vieux formulaires Web, Asp.Net MVC - quelqu'un d'autre écrit-il du balisage sur Razor?), Et Angular est populaire dans une entreprise difficile.
Si vous êtes depuis longtemps passé de désespoir sur le devant des enders et êtes passé à la nouvelle angulaire et React, alors ...
Oui, messieurs, les développeurs du backend, nous avions à nouveau l'espoir que les connaissances acquises au fil des ans ne seraient pas perdues dans la tête. Et cet espoir est la technologie Blazor de Microsoft.
Après avoir ouvert le projet par défaut que le studio crée lors de la création du projet Blazor, puis après avoir examiné plusieurs articles, je me suis glissé dans l'idée que tout est vraiment si mauvais et que le code et le balisage sont toujours dans le même fichier, comme par exemple ici (ci-après, tous les exemples seront montrés sur la base de Projet de modèle d'application Blazor Server de Visual Studio 2019 avec .Net Core 3.1 installé):
Rien ne confond ici?
À mon avis, tout ce qui est rempli de rouge a peu à voir avec le contenu que ce composant représente et vous devez vous en débarrasser. Pourquoi?
- Eh bien, premièrement, le développeur front-end qui travaillera avec vous en même temps sur ce contrôle sera un peu dérouté par des symboles qui lui sont incompréhensibles et chaque fois qu'il sera prudent et vous posera des questions quand il aura besoin de changer quelque chose dans le morceau de code encadré par le balisage Razor .
- Bien sûr, les frontenders seront prudents, mais à coup sûr, vous rencontrerez périodiquement le fait qu'après certaines manipulations, votre page ne fonctionnera pas comme prévu ou ne fonctionnera tout simplement pas.
- Si vous pensez que les développeurs frontaux ne seront pas nécessaires, car tout peut maintenant être écrit en C #, alors vous vous trompez. Dans tous les cas, vous devez styliser le contrôle et cela sera fait soit par le développeur frontal, soit par le typographe qui, souvent, ne sait pas ce qu'est C #.
- Au début, il semblera que le code est petit et qu'il n'encombre pas beaucoup la mise en page, c'est trompeur, dans un projet en pleine croissance, vous passerez très rapidement de la scène, de la démo technologique à «merde ce qui se passe ici». Plus d'une fois, je suis tombé sur le fait que depuis SQL Web Controls ou directement sur la page .cshtml, une requête SQL dans la base de données a été publiée, oui, je ne plaisante pas. Très souvent, des développeurs expérimentés qui vous ont torturé hier dans une interview sur la sécurité sociale, connaissant déjà les principes SOLIDES, écrivent demain la logique métier, directement dans le balisage.
Je pense que je vous ai déjà fait assez peur, maintenant je vais vous dire comment éviter les problèmes ci-dessus, d'autant plus que cela se fait très simplement. Et ce sera génial si vous adoptez les approches suivantes en règle générale lors de la création d'un nouveau composant Razor. Donc, la première approche.
Classe de base
La première et, jusqu'à récemment, la seule approche.
Vous créez une classe de base dans laquelle se trouvera toute la logique d'affichage, pour le contrôle de l'exemple ci-dessus. Créez un nouveau fichier en utilisant le modèle
[Nom du contrôle] .razor.cs
Ici, le studio viendra à notre aide et construira à partir de deux fichiers quelque chose comme dans l'image ci-dessous:
Comme vous pouvez le voir, le studio est assez intelligent et a compris lui-même ce que vous en attendiez. Le contrôle a été regroupé avec le fichier dans lequel nous voulons placer notre code.
Si vous ouvrez un nouveau fichier maintenant, le nom de la classe FetchData sera souligné par une ligne ondulée rouge, tout est vrai, car malgré le fait que dans FetchData.razor vous ne verrez nulle part les déclarations de classe avec le nom FetchData , plus tard après la compilation du projet, il apparaîtra, je montrerai il est inférieur et le nom de classe FetchData est donc déjà réservé. Nous n'avons d'autre choix que d'utiliser la convention selon laquelle nous placerons la logique d'affichage (et seulement elle !!!) dans la classe FetchDataBase, c'est-à-dire que le nom de la classe sera formé par le modèle:
[ControlName] Base
Bien sûr, vous pouvez être confus et écrire votre propre analyseur statique, qui vérifiera ces fichiers pour chaque composant, pourquoi pas?
Ensuite, nous devons hériter de cette classe de ComponentBase . N'oubliez pas d'ajouter
en utilisant Microsoft.AspNetCore.Components ;
Et voici ce que nous avons obtenu:
Wow, la classe est prête à transférer la logique d'affichage ici, que nous avons maintenant la possibilité d'écrire complètement en C #, n'est-ce pas du bonheur? :)
Mais alors que le composant Razor lui-même ne sait rien de notre fichier, seul Visual Studio sait qu'ils ont quelque chose en commun.
Alors, faites l'astuce suivante:
Nous avons hérité du composant Razor de la classe FetchDataBase .
Laissez le code C # qui existe toujours dans FetchData.razor ne vous dérange pas.
À l'heure actuelle, nous allons transférer toute la logique d'affichage dans notre soi-disant code derrière le fichier:
Ce qui s'est passé, eh bien, tout d'abord, nous avons ajouté en utilisant-et. Sur les contrôles Razor, vous ne les verrez pratiquement pas, car il est habituel de les ajouter à _Imports.razor . Il y a déjà ajouté certains des plus utilisés.
Ensuite, nous injectons à travers la propriété, comme vous pouvez le voir, notre DI préféré fonctionne très bien.
Il vous suffit de marquer la propriété implémentée avec l'attribut [Inject] . Dans le composant Razor, il était étiqueté Inject . Autrement dit, les changements sont minimes.
Eh bien, suit ensuite la propriété, dans laquelle nous chargeons les informations affichées, elle doit être au moins protégée (car le contrôle Razor hérite de la classe actuelle). Ou public si vous décidez de permettre l'initialisation de l'extérieur, dans ce cas vous devrez toujours le marquer avec l'attribut [Parameter] . Dans les versions antérieures de Blazor, il était assez protégé , mais maintenant l'analyseur de studio vous le grondera.
En principe, vous pouvez ajouter un constructeur à cette classe et y travailler, mais ce n'est pas recommandé, il est préférable de placer toute la logique d'initialisation dans la méthode OnInitializedAsync ()
C'est tout ce qui reste dans FetchData.razor
Il y avait des balises Razor entrecoupées, mais comment pourrait-il en être autrement, nous devons toujours afficher nos données d'une manière ou d'une autre. Mais le code C # pur a complètement disparu. Et c'est super à mon avis. Je vous conseille de suivre initialement une approche similaire et ensuite ni vous ni vos collègues ne vous prendront la tête lorsque votre contrôle atteindra de grandes tailles.
La chose la plus importante est de savoir si cela fonctionne, vérifions maintenant:
Super, c'est comme s'ils n'avaient rien cassé =)
Classe partielle
Et donc la deuxième approche, qui est apparue récemment ( https://docs.microsoft.com/en-us/aspnet/core/blazor/components?view=aspnetcore-3.1#partial-class-support ), mais très probablement remplacera complètement précédent. À la demande des travailleurs, .Net Core 3.1 a ajouté la possibilité de créer une classe partielle pour les contrôles Razor. Donc, nous laissons presque tout comme dans l'approche précédente, mais maintenant nous n'avons pas besoin d'hériter de ComponentBase, et la classe peut être appelée de la même manière que le composant, c'est-à-dire que sa signature sera la suivante:
classe partielle publique [ComponentName]
Comme vous pouvez le voir ci-dessous, les changements sont minimes, dans le code derrière nous nous sommes débarrassés de l'héritage de ComponentBase et avons marqué la classe comme partielle
Le fichier de balisage est également un peu simplifié, nous nous sommes également débarrassés de l'héritage de FetchDataBase, cette classe a cessé d'exister en raison de son inutilité.
Comme vous pouvez le voir, il existe deux approches pour garder votre balisage propre. Celui que vous choisissez dépend de vous. Malheureusement, ce serait bien pour le studio de générer immédiatement du code-back lors de la création d'un nouveau composant. Maintenant, cela est activement discuté et, comme le disent les développeurs, à l'avenir, une telle probabilité sera ajoutée s'il y a une demande, et elle le sera certainement.
Alors, maintenant, en quoi notre composant Razor se transforme-t-il:
C'est familier, n'est-ce pas?) Tous ceux qui ont créé leurs composants Razor Asp.Net MVC trouveront très familier le contenu du fichier généré automatiquement.
J'espère que vous en avez appris un peu plus sur Blazor aujourd'hui grâce à mon premier article sur Habr. Laissez ci-dessous les critiques, questions et demandes de nouveaux articles =)