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.
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.
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 :
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 :
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 :
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 :
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 :
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 :
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.
Collaborer avec nous sur GitHub
La source de ce contenu se trouve sur GitHub, où vous pouvez également créer et examiner les problèmes et les demandes de tirage. Pour plus d’informations, consultez notre guide du contributeur.
Commentaires sur .NET
.NET est un projet open source. Sélectionnez un lien pour fournir des commentaires :
Ce module vous guide tout au long des étapes de création d’un projet d’accès aux données. Vous vous connectez à une base de données relationnelle et créez, lisez, mettez à jour et supprimez des requêtes (CRUD) à l’aide d’Entity Framework Core (EF Core).