Utilisation de Microsoft.Extensions.Logging dans EF Core

Article
09/13/2023

Microsoft.Extensions.Logging est un mécanisme de journalisation extensible avec des fournisseurs de plug-ins pour de nombreux systèmes de journalisation courants. Les plug-ins fournis par Microsoft (par exemple, Microsoft.Extensions.Logging.Console) et les plug-ins tiers (par exemple, Serilog.Extensions.Logging) sont disponibles en tant que packages NuGet.

Entity Framework Core (EF Core) s’intègre entièrement à Microsoft.Extensions.Logging. Toutefois, envisagez d’utiliser la journalisation simple afin de simplifier la journalisation, en particulier pour les applications qui n’utilisent pas l’injection de dépendances.

applications ASP.NET Core ;

Microsoft.Extensions.Logging est utilisé par défaut dans les applications ASP.NET Core. L’appel AddDbContext ou AddDbContextPool permet à EF Core d’utiliser automatiquement la configuration de journalisation configurée via le mécanisme ASP.NET standard.

Autres types d’applications

D’autres types d’applications peuvent utiliser GenericHost pour obtenir les mêmes modèles d’injection de dépendances que ceux utilisés dans ASP.NET Core. AddDbContext ou AddDbContextPool peut ensuite être utilisé comme dans les applications ASP.NET Core.

Microsoft.Extensions.Logging peut également être utilisé pour les applications qui n’utilisent pas l’injection de dépendances, bien que la journalisation simple soit plus facile à configurer.

Microsoft.Extensions.Logging nécessite la création d’un LoggerFactory. Cette fabrique doit être stockée en tant qu’instance statique/globale quelque part et utilisée chaque fois qu’un DbContext est créé. Par exemple, il est courant de stocker la fabrique d’enregistreurs d’événements en tant que propriété statique sur DbContext.

EF Core 3.0 et versions ultérieures
EF Core 2.1

public static readonly ILoggerFactory MyLoggerFactory
    = LoggerFactory.Create(builder => { builder.AddConsole(); });

public static readonly LoggerFactory MyLoggerFactory
    = new LoggerFactory(new[] { new ConsoleLoggerProvider((_, __) => true, true) });

Avertissement

Dans EF Core 2.1, il est très important que les applications ne créent pas une nouvelle instance LoggerFactory pour chaque instance DbContext. Cela entraînerait une fuite de mémoire et des performances médiocres. Cela a été corrigé dans EF Core 3.0 et versions ultérieures.

Cette instance singleton/globale doit ensuite être enregistrée auprès d’EF Core sur le DbContextOptionsBuilder. Par exemple :

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .UseLoggerFactory(MyLoggerFactory)
        .UseSqlServer(@"Server=(localdb)\mssqllocaldb;Database=EFLogging;Trusted_Connection=True;ConnectRetryCount=0");

Obtention de messages détaillés

Conseil

OnConfiguring est toujours appelé lorsque AddDbContext est utilisé ou qu’une instance DbContextOptions est transmise au constructeur DbContext. C’est donc l’emplacement idéal pour appliquer la configuration du contexte, quel que soit le mode de construction du DbContext.

Données sensibles

Par défaut, EF Core n’inclura pas les valeurs des données dans les messages d’exception. Cela est dû au fait que ces données peuvent être confidentielles et qu’elles pourraient être révélées en production si une exception n’est pas gérée.

Toutefois, connaître les valeurs de données, en particulier celles des clés, peut s’avérer très utile lors du débogage. Cela peut être activé dans EF Core en appelant EnableSensitiveDataLogging(). Par exemple :

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder.EnableSensitiveDataLogging();

Exceptions de requête détaillées

Pour des raisons de performances, EF Core n’enveloppe pas chaque appel à la lecture d’une valeur du fournisseur de base de données dans un bloc try-catch. Toutefois, cela entraîne parfois des exceptions difficiles à diagnostiquer, notamment lorsque la base de données renvoie une valeur NULL alors que le modèle ne l’autorise pas.

En activant EnableDetailedErrors, EF introduira ces blocs try-catch et fournira ainsi des erreurs plus détaillées. Par exemple :

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder.EnableDetailedErrors();

Configuration pour des messages spécifiques

L’API EF Core ConfigureWarnings permet aux applications de modifier ce qui se passe lorsqu’un événement spécifique se produit. Cela peut être utilisé pour :

Modifier le niveau du journal auquel l’événement est journalisé
Ignorer complètement la journalisation de l’événement
Lever une exception lorsque l’événement se produit

Modifier le niveau de journal d’un événement

Il peut parfois être utile de modifier le niveau de journal prédéfini pour un événement. Par exemple, cela peut être utilisé pour promouvoir deux événements supplémentaires de LogLevel.Debug à LogLevel.Information :

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .ConfigureWarnings(
            b => b.Log(
                (RelationalEventId.ConnectionOpened, LogLevel.Information),
                (RelationalEventId.ConnectionClosed, LogLevel.Information)));

Supprimer la journalisation d’un événement

De la même façon, un événement individuel peut être supprimé de la journalisation. Cela est particulièrement utile pour ignorer un avertissement qui a été examiné et compris. Par exemple :

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .ConfigureWarnings(b => b.Ignore(CoreEventId.DetachedLazyLoadingWarning));

Lancer un événement

Enfin, EF Core peut être configuré pour lancer un événement donné. Cela est particulièrement utile pour changer un avertissement en erreur. (En effet, c’était l’objectif initial de la méthode ConfigureWarnings, d’où son nom.) Exemple :

protected override void OnConfiguring(DbContextOptionsBuilder optionsBuilder)
    => optionsBuilder
        .ConfigureWarnings(b => b.Throw(RelationalEventId.QueryPossibleUnintendedUseOfEqualsWarning));

Filtrage et autre configuration

Consultez Journalisation dans .NET pour obtenir des conseils sur le filtrage des journaux et d’autres configurations.

Les événements de journalisation EF Core sont définis dans l’un des éléments suivants :

CoreEventId pour les événements communs à tous les fournisseurs de base de données EF Core
RelationalEventId pour les événements communs à tous les fournisseurs de base de données relationnelles
Une classe similaire pour les événements spécifiques au fournisseur de base de données actuel. Par exemple, SqlServerEventId pour le fournisseur SQL Server.

Ces définitions contiennent les ID des événements, le niveau de journalisation et la catégorie de chaque événement, tels qu’ils sont utilisés par Microsoft.Extensions.Logging.

Partager via