Utilisation d'une approche code-behind pour les composants de blazor

Dans cet article, nous verrons s'il est utile d'utiliser un code-behind dans votre développement Blazor, quels en sont les avantages et ce à quoi nous attendre lors de la refactification des composants existants.

Lorsque vous utilisez Blazor, l'architecture de composant par défaut est d'avoir tout le balisage et la logique mélangés dans un seul fichier (.razor). Lorsque les composants sont simples, cette approche fonctionne bien. Cependant, plus la complexité augmente, plus il devient difficile de gérer l’ensemble d’un composant. L'utilisation d'une approche "code-behind" permet de séparer les balises et la logique dans leurs propres fichiers. Dans cet article, nous verrons s'il est utile d'utiliser un code de retard, comment nous en tirons profit et à quoi nous attendre lors de la refactification des composants existants.

Approche de fichier unique

Commençons par un rapide examen du fichier unique. approche fichier. Nous allons utiliser le composant FetchData du modèle par défaut d'ASP.NET comme exemple. Le composant FetchData affiche un tableau HTML des données de prévisions météorologiques en bouclant sur les données fournies par un service. Le composant utilise des directives, HTML / Razor et un bloc @code ;

Le balisage du composant est assez détaillé. Pesée à 30 + lignes le balisage lui-même étend la longueur du fichier, ce qui nous oblige à faire défiler vers le bas pour trouver la logique des composants représentée par un bloc @code .

Gardez à l'esprit que ce composant est encore assez simple. À mesure que la complexité augmente, chaque section grandit. Cela signifie que nous aurons éventuellement plus de directives, en utilisant des instructions, du balisage et de la logique dans notre bloc de code. Bien qu'il puisse être pratique de disposer d'un fichier tout compris, sa maintenance risque de devenir fastidieuse en raison du défilement constant entre le balisage et la logique.

Re-factoriser le composant FetchData à l'aide d'un fichier code-behind, voir comment il s'améliore. l'expérience globale du développeur.

Approche code-derrière

Code-behind est un terme courant désignant la technique consistant à utiliser un fichier de code distinct pour représenter l'ensemble de la logique d'une page, d'une vue ou d'un composant correspondant. Créer un code-behind dans Blazor nécessite quelques étapes, mais heureusement, il est supporté par le framework, donc la configuration est assez simple. Pour compléter notre code-behind, nous devrons créer une classe, puis lier le code-behind à notre balisage. Une fois la structure en place, nous pouvons passer au-dessus de notre logique existante.

Création et liaison d'un code-derrière

Premièrement, nous avons besoin d'un fichier de classe qui représente notre code-derrière. Il s'agit d'une classe .NET standard, mais nommer est très important. Lorsque nous créons notre fichier code-behind, nous devons considérer à la fois le nom du fichier et celui de la classe, car ils peuvent grandement affecter notre expérience de développeur.

Commençons par le nom du fichier. Lorsque nous ajoutons le nom du fichier, nous devrions suivre une convention commune de [componentName] Base.razor.cs . L'extension .razor.cs est comprise par Visual Studio et sera correctement imbriquée dans la fenêtre de l'explorateur de fichiers. Étant donné que le composant occupe déjà un nom de classe, nous devons ajouter le suffixe Base à notre nom de classe, ce qui lui donnera un nom de classe unique. Le fichier final code-behind devrait être FetchData.razor.cs avec un nom de classe de FetchDataBase .

Ensuite, nous devrons lier la partie de balisage du composant (.razor) au code-behind (.razor.cs). Dans le fichier code-behind, nous hériterons de ComponentBase . Lors de l'héritage de ComponentBase dans Visual Studio, le raccourci ctrl + . ajoutera l'instruction using à l'aide de Microsoft.AspNetCore.Components; qui est l’espace de noms pour ComponentBase Au moment de la rédaction du raccourci ctrl + . de nombreux outils de refactoring pour Visual Studio ne sont pas disponibles. les raccourcis soulignent l'importance des fichiers code-behind dans Blazor.

 utilisant Microsoft.AspNetCore.Components;

espace de noms MyApp.Pages
{
    Classe publique FetchDataBase: ComponentBase
    {
    }
}

Nous allons utiliser un processus similaire dans notre fichier de balisage pour compléter le lien entre les deux fichiers. En haut du balisage du composant, nous hériterons de notre code-behind en utilisant la directive @inherits . L'héritage de FetchDataBase forme un composant complet et nous n'avons plus besoin d'utiliser le bloc @code pour définir la logique de notre composant.

 @inherits FetchDataBase
@page "/ fetchdata"
@ en utilisant WebApplication33.Data
@inject WeatherForecastService ForecastService

... balisage

@code {...}

Nous pouvons maintenant migrer tout le code du bloc @code vers notre code-behind, ainsi que quelques directives.

Migration de @code vers code-derrière

La plupart de la logique de notre bloc @code peut être copiée directement telle quelle dans le code-behind sans modification, toutefois, quelques petites mises à jour devront être apportées. Le bloc @code est limité à la classe du composant, tandis que le champ code-behind est la classe de base du composant. Tout ce que nous voudrions référencer dans la classe de base via le balisage doit être marqué protégé . Dans le cas de FetchData, la variable pronostics est utilisée dans le balisage des composants; elle doit donc être protégée ou publique pour être visible par la classe FetchData . Dans le code de prévisions météorologiques WeatherForecast []; devient les prévisions météorologiques protégées WeatherForecast []; .

 Classe publique FetchDataBase: ComponentBase
    {
        prévisions WeatherForecast [] protégées;

        ...
    } 

Au fur et à mesure que nous déplaçons le code dans notre code-behind, des instructions d'utilisation supplémentaires seront nécessaires, car le code-behind ne tire pas parti des valeurs globales dans _Imports.razor . Encore une fois, c’est là que l’outillage standard devient pratique avec ctrl + . réduire au minimum les espaces-noms manquants.

 à l'aide de Microsoft.AspNetCore.Components;
using System.Threading.Tasks; // Ajouté par ctrl +.
using MyApp.Data; // Ajouté par ctrl +.

espace de noms MyApp.Pages
{
    Classe publique FetchDataBase: ComponentBase
    {
        prévisions WeatherForecast [] protégées;

        protégé remplacer async Task OnInitAsync ()
        {
            prévisions = attendre ForecastService.GetForecastAsync (DateTime.Now);
        }
    }
}

Avec tout le code migré, il nous reste à nous attaquer à une dernière étape, l'injection de dépendance (DI).

Injection de dépendance dans Blazor Code-Behind

L'injection de dépendance dans Balisage Razor est traitée par la directive @inject . Bien que la directive soit disponible dans les classes code-behind, elle est écrite de manière très différente et, à première vue, peut ne pas être évidente. Pour utiliser l'injection de dépendance dans un fichier code-behind, nous allons utiliser l'attribut [Inject] et l'appliquer à une propriété du type que nous aimerions injecter, par exemple: [Inject] MyType MyProp {get; ensemble; } .

 utilisant Microsoft.AspNetCore.Components;
en utilisant le système;
using System.Threading.Tasks;
using MyApp.Data;

espace de noms MyApp.Pages
{
    Classe publique FetchDataBase: ComponentBase
    {
        [Inject] WeatherForecastService ForecastService {get; ensemble; }

        prévisions WeatherForecast [] protégées;

        protégé remplacer async Task OnInitAsync ()
        {
            prévisions = attendre ForecastService.GetForecastAsync (DateTime.Now);
        }
    }
}

Avec l'attribut [Inject] ajouté, le composant peut maintenant résoudre le service et nous n'avons plus besoin de la directive dans le balisage Razor. Nous pouvons nettoyer notre balisage en supprimant les directives @inject et @using ainsi que les blocs @code .

Code-Behind Final Pensées

Lorsque nous avons commencé les directives du composant, le balisage et la logique étaient tous contenus dans un seul fichier. Une approche de fichier unique offre des avantages en termes de simplicité et convient parfaitement aux composants de petite taille, mais elle n’évolue tout simplement pas correctement. Une fois que notre composant nécessite un balisage ou une logique complexe, il est facile de se perdre dans le fichier volumineux et / ou d'être confondu avec deux manières différentes d'exprimer le code. De plus, nous perdons l'accès à certains des outils de productivité les plus précieux de Visual Studio.

Le processus de conversion d'un composant existant en code-behind est relativement simple. Quelques modifications de code sont nécessaires en ce qui concerne à l'aide d'instructions de niveaux de protection et d'injection de dépendance. Pour la plupart, Visual Studio nous aide même à apporter les corrections nécessaires pour réussir la compilation.

Lorsque la transition est terminée, nous bénéficions de rôles clairement définis pour le balisage et la logique avec Si nous devons voir le composant dans son intégralité, nous pouvons maintenant casser les deux fenêtres côte à côte et nous concentrer sur la tâche à accomplir.

Nouveau chez Blazor?

Si vous êtes un novice Blazor et souhaitez commencer à apprendre rapidement, consultez la série de vidéos gratuite Blazor Quick Start Dans cette série de vidéos pédagogiques, vous apprendrez à connaître ASP.NET Core Blazor et à apprendre à utiliser les concepts de Blazor tels que: composants, événements , liaison de données, etc. Le parcours est guidé par moi, Ed Charbeneau un MVP Microsoft à quatre reprises