Les meilleures pratiques d’injection de dépendance, les cas d’utilisation

Apprenez les meilleures pratiques pour utiliser l’injection de dépendance dans Blazor et les différences entre le serveur Blazor et le Blazor WebAssembly.

L’injection de dépendance est un modèle de conception fondamental dans le développement du noyau ASP.NET et du Blazor. Il aide les développeurs à mettre en œuvre des applications modulaires et maintenables en découplant les implémentations.

Par exemple, un Users La page peut faire référence à un UserService par son interface. Au moment de l’exécution, le système d’injection de dépendance injecte une instance du UserService Lors de la rendu le Users page.

Dans cet article, nous nous concentrerons sur les principes fondamentaux de l’injection de dépendance dans Blazor et découvrirons les meilleures pratiques et les cas d’utilisation au-delà de l’injection des services dans les pages du blazor. Nous apprendrons également une nouvelle fonctionnalité de .NET 9.

Introduction à l’injection de dépendance dans Blazor

Il existe plusieurs options pour injecter des services dans les composants du rasoir.

Toutes les options ont en commun que vous devez d’abord enregistrer la dépendance avec le système de dépendance. Habituellement, vous enregistrez une dépendance dans le Program.cs Fichier de votre application basée sur ASP.NET, y compris les applications Web Blazor.

builder.Services.AddScoped<IUserService, UserService>();

Nous utilisons le WebApplicationBuilder Instance pour accéder à son Services propriété de type IServiceCollection et enregistrer l’implémentation du service utilisateur pour le IUserService interface.

Note: Les différentes vies de service ou lunettes seront couvertes plus loin dans cet article.

Injecter la directive

Le @inject La directive nous permet d’injecter des implémentations de service dans des fichiers de rasoir.

@inject IUserService UserService

Cette ligne simple en haut du composant de rasoir nous permet de définir une variable de type IUserService qui recevra une instance lors de l’exécution.

Il rend la variable disponible dans le modèle et les sections de code du composant Razor.

Attribut injecter

Nous pouvons également injecter des services dans un composant de rasoir avec le Inject attribut. Au lieu d’utiliser le @injectune directive de rasoir, nous utilisons un C # régulier attribut.

@code { 
    [Inject] 
    private IUserService UserService { get; set; }
}

Cette approche nécessite un bloc de code ou un fichier de code de code, tandis que le @inject Direct offre une manière plus simple indépendante d’une section de code.

Injection de constructeur

En commençant par .NET 9, nous pouvons utiliser l’injection de constructeur dans des composants de rasoir similaires à d’autres classes C # régulières.

@code {
    private IUserService _userService;

    public Home(IUserService userService)
    {
        _userService = userService;
    }
}

Dans la section Code, nous ajoutons un constructeur et injectons une instance du IUserService interface que nous stockons dans un domaine privé.

Conclusion et stratégie d’injection de service préférée

Les trois options d’injection de services différentes ont des avantages et des inconvénients. J’utilise presque exclusivement le @inject Directive dans mes applications Blazor car elle est simple et concise.

Injection de constructeur est une alternative bienvenue. Il fournit un contrôle total et le même mécanisme que les autres applications C #, telles que les applications de bureau WPF ou les contrôleurs ASP.NET Core WebAPI. Il aide les développeurs à la transition vers Blazor avec un environnement connu.

Cependant, je ne vois pas de cas d’utilisation où j’utiliserais injection de biens Utilisation de l’attribut Inject.

Évaluation de l’injection de dépendance dans Blazor

Semblable aux applications Web régulières ASP.NET Core, nous avons trois lunettes de vie de service différentes –Singleton, Transitoire et Dans la portée.

Nous décidons quelle vie nous voulons utiliser pour un service spécifique lors de l’enregistrement avec le conteneur d’injection de dépendance, généralement dans le Program.cs déposer.

Apprenons les différentes lunettes à vie et si elles se comportent différemment selon que nous utilisons l’interactivité Blazor Server ou Blazor WebAssembly (exécuter côté serveur ou côté client).

Singleton

Singleton Les services sont instanciés une fois et partagés sur l’ensemble de l’application, ce qui les rend idéaux pour les paramètres d’état ou de configuration à l’échelle de l’application.

Puisqu’ils ne sont instanciés qu’une seule fois, cela n’a pas un grand impact si l’initialisation prend un peu plus de temps.

Transitoire

Transitoire Les services créent une nouvelle instance à chaque fois qu’ils sont injectés, ce qui les rend utiles pour les opérations apatrides qui sont rapidement initialisées.

Vous ne voulez pas définir les services comme transitoires qui ont beaucoup de code d’initialisation ou lent.

Dans la portée

Dans la portée Les services sont particulièrement importants dans Blazor Server, où ils sont liés au circuit SignalR d’un utilisateur (session).

Il en fait le choix préféré pour les services qui ont besoin de maintenir des données spécifiques à l’utilisateur ou qui sont en quelque sorte liés à l’utilisateur (authentification). Dans Blazor Server, la portée peut être considérée comme «singleton-per-user».

Blazor Server vs Blazor WebAssembly

Pour l’interaction Blazor WebAssembly, l’application / composant Blazor s’exécute sur le client, et il y a Aucune connexion signalr entre le serveur et le client.

Cela signifie que, pour chaque singleton et service de portée, un instance par navigateur est créé.

L’enregistrement d’un service en tant que singleton ne vous permet pas de partager des informations entre différents clients / utilisateurs lors de l’utilisation d’interactivité Blazor WebAssembly, alors qu’il fonctionne lors de l’utilisation d’interactivité du serveur Blazor.

La portée transitoire est la même pour Blazor Server et Blazor WebAssembly, ce qui signifie qu’un nouveau service est créé pour chaque injection.

Comprendre les nuances de ces vies permet une utilisation optimale des ressources et aide à prévenir les comportements involontaires.

Utilisation de DI pour la gestion de l’État, les services de données et les tests de composants

L’injection de dépendance joue un rôle crucial dans la gestion de l’état, la récupération des données et les tests dans les applications Blazor.

Pour la gestion de l’État, l’injection de dépendance permet aux services de conserver et de gérer les données partagées. Cette approche est assez bonne dans de nombreux scénarios et évite la nécessité de modèles complexes axés sur les événements.

L’injection de dépendance sépare le consommateur du producteur et permet une meilleure testabilité des applications et une réutilisabilité des composants.

Par exemple, si vous résumez un comportement dans un service, vous pouvez injecter le service dans plusieurs composants de rasoir et réutiliser la même fonctionnalité.

Vous ne souhaitez pas implémenter la logique d’accès aux données directement dans vos composants de rasoir. Au lieu de cela, vous souhaitez implémenter les services de données que vous pouvez exploiter pour charger et enregistrer des données. Encore une fois, cela aide à la testabilité, à la maintenabilité et à la réutilisabilité.

En tirant parti de l’injection de dépendance efficace, nous pouvons construire des applications de blazor évolutives, maintenables et testables.

Meilleures pratiques pour l’injection de dépendance en Blazor

Les meilleures pratiques suivantes aident à mettre en œuvre des applications Web Blazor robustes, maintenables et réutilisables:

• Enregistrez les services en utilisant la bonne durée de vie. Choisissez entre les vies de singleton, transitoires et dans les parasites de manière appropriée pour éviter le partage de données involontaire ou la consommation de mémoire inutile.
• Utilisez des interfaces pour les services. Définissez les interfaces de vos services pour améliorer la testabilité et la flexibilité.
• Utilisez la bonne stratégie de découplage. Divisez votre comportement en trop de petits services, et vous vous retrouverez avec d’innombrables dépendances. Mettez tout dans un seul service, l’ensemble de votre application en dépendra. Choisissez un terrain d’entente sensible.
• Utilisez l’injection de dépendance pour la configuration de l’application. Au lieu d’accéder directement à la configuration dans vos composants, implémentez un service qui valide la configuration et fournit des structures de données appropriées.

L’application de ces quatre meilleures pratiques vous aidera à mettre en œuvre des applications de blazor plus maintenables et extensibles.

Conclusion

L’injection de dépendance est un schéma important pour le développement Web de Core ASP.NET, et Blazor spécifiquement.

C’est un schéma simple et vous vous rendez rapidement à la vitesse. Cependant, la compréhension des détails, telles que les durées de vie, et l’application des meilleures pratiques sont essentielles à la mise en œuvre d’applications Web Blazor maintenables, robustes et flexibles.

Si vous voulez en savoir plus sur le développement du blazor, vous pouvez regarder mon Cours crash gratuit du blazor sur youtube. Et restez à l’écoute du blog Telerik pour en savoir plus Bases du blazor.