Partager via


Utilisation de Microsoft.Extensions.Logging dans EF Core

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 pour un moyen plus simple de journaliser, 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 fait qu'EF Core utilise automatiquement la configuration de journalisation définie via le mécanisme standard d'ASP.NET.

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 puisse être 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.

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

Cette instance singleton/globale doit ensuite être inscrite 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 / Astuce

OnConfiguring est toujours appelé lorsque AddDbContext est utilisé ou qu’une instance DbContextOptions est passée au constructeur DbContext. Cela permet d’appliquer la configuration de contexte, quel que soit le mode de construction de DbContext.

Données sensibles

Par défaut, EF Core n’inclut pas les valeurs des données dans les messages d’exception. Cela est dû au fait que ces données peuvent être confidentielles et peuvent ê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 pour les clés, peut être 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’encapsule pas chaque appel pour lire une valeur du fournisseur de base de données dans un bloc try-catch. Toutefois, cela entraîne parfois des exceptions difficiles à diagnostiquer, en particulier lorsque la base de données retourne une valeur NULL lorsqu’elle n’est pas autorisée par le modèle.

L’activation de EnableDetailedErrors par EF provoquera l’introduction de 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 est rencontré. 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

Modification du niveau de journalisation pour un événement

Il peut parfois être utile de modifier le niveau de journalisation 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 exclu 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));

Déclencher un événement

Enfin, EF Core peut être configuré pour lever pour un événement donné. Cela est particulièrement utile pour modifier un avertissement en une erreur. (En effet, c’était l’objectif original de ConfigureWarnings la méthode, donc le nom.) Par exemple:

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

Filtrage et autre configuration

Consultez la 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
  • 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 d’événement, le niveau de journal et la catégorie de chaque événement, comme utilisé par Microsoft.Extensions.Logging.