Injecter des dépendances avec Scoped vs Singleton dans .NET Core
L'injection de dépendances est un concept fondamental dans le développement logiciel moderne et .NET Core la prend en charge de manière native. Cette pratique permet de découpler les différentes parties de votre application, favorisant la modularité, la testabilité et la maintenabilité. Mais comment choisir entre les durées de vie Scoped et Singleton pour vos dépendances ?
Comprendre les Durées de Vie des Dépendances
.NET Core offre plusieurs durées de vie pour vos dépendances :
- Transient: Une nouvelle instance est créée à chaque requête.
- Scoped: Une seule instance est créée par requête HTTP.
- Singleton: Une seule instance est créée pour toute l'application.
Scoped vs Singleton : Quand Choisir Quelque Chose ?
Scoped est idéal pour les dépendances qui nécessitent un état spécifique à la requête HTTP, comme un contexte de base de données ou des services qui gèrent des données liées à un utilisateur.
Exemple :
public interface IUserService
{
// Méthodes pour gérer les utilisateurs
}
public class UserService : IUserService
{
private readonly MyDbContext _context;
public UserService(MyDbContext context)
{
_context = context;
}
// Implémentation des méthodes
}
// Dans votre Startup.cs
services.AddScoped();
Singleton convient pour les dépendances qui peuvent être partagées entre toutes les requêtes, comme les configurations, les caches ou les services qui ne gèrent pas d'état lié à la requête.
Exemple :
public interface IConfigService
{
// Méthodes pour accéder aux configurations
}
public class ConfigService : IConfigService
{
private readonly IConfiguration _configuration;
public ConfigService(IConfiguration configuration)
{
_configuration = configuration;
}
// Implémentation des méthodes
}
// Dans votre Startup.cs
services.AddSingleton();
Attention aux pièges !
Il est important de bien comprendre l'impact de chaque durée de vie sur vos dépendances.
Une dépendance Scoped partagée entre plusieurs requêtes peut entraîner des problèmes d'état. Par exemple, si vous utilisez une dépendance Scoped pour stocker des données utilisateur dans une variable, ces données seront accessibles par d'autres requêtes, ce qui peut mener à des erreurs ou des violations de sécurité.
Une dépendance Singleton qui dépend d'une variable non-thread-safe peut entraîner des problèmes de concurrence. Si plusieurs threads accèdent à la même instance de dépendance Singleton en même temps, ils peuvent modifier la variable en même temps, ce qui peut mener à des résultats imprévisibles.
En résumé
Le choix entre Scoped et Singleton dépend de la nature de votre dépendance et de son utilisation. Utilisez Scoped pour les dépendances liées à une requête spécifique et Singleton pour les dépendances partageables.
N'oubliez pas de prendre en compte les potentialités de problèmes d'état et de concurrence lorsque vous choisissez une durée de vie pour vos dépendances.