Использование Microsoft.Extensions.Logging в EF Core

  • Статья

Microsoft.Extensions.Logging — это расширяемый механизм ведения журнала с поставщиками подключаемых модулей для многих распространенных систем ведения журналов. Подключаемые модули Майкрософт (например , Microsoft.Extensions.Logging.Console) и сторонние подключаемые модули (например , Serilog.Extensions.Logging) доступны в виде пакетов NuGet.

Entity Framework Core (EF Core) полностью интегрируется с Microsoft.Extensions.Logging. Однако рекомендуется использовать простое ведение журнала для более простого способа журналов, особенно для приложений, которые не используют внедрение зависимостей.

Приложения ASP.NET Core

Microsoft.Extensions.Logging используется по умолчанию в приложениях ASP.NET Core. Вызов AddDbContext или AddDbContextPool автоматическое использование EF Core настройки ведения журнала с помощью обычного механизма ASP.NET.

Другие типы приложений

Другие типы приложений могут использовать GenericHost , чтобы получить те же шаблоны внедрения зависимостей, что и в ASP.NET Core. AddDbContext или AddDbContextPool можно использовать так же, как и в приложениях ASP.NET Core.

Microsoft.Extensions.Logging также можно использовать для приложений, которые не используют внедрение зависимостей, хотя простое ведение журнала может быть проще настроить.

Microsoft.Extensions.Logging требует создания LoggerFactoryобъекта . Эта фабрика должна храниться как статический или глобальный экземпляр и каждый раз при создании DbContext. Например, обычно фабрика ведения журнала хранится в виде статического свойства в DbContext.

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

Затем этот одноэлементный или глобальный экземпляр следует зарегистрировать в EF Core в этом экземпляре DbContextOptionsBuilder. Например:

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

Получение подробных сообщений

Совет

OnConfiguring по-прежнему вызывается при использовании AddDbContext или экземпляре DbContextOptions передается конструктору DbContext. Это делает его идеальным местом для применения конфигурации контекста независимо от того, как создается DbContext.

Конфиденциальные данные

По умолчанию EF Core не будет включать значения любых данных в сообщениях об исключениях. Это связано с тем, что такие данные могут быть конфиденциальными и могут быть выявлены в рабочей среде, если исключение не обрабатывается.

Однако знание значений данных, особенно для ключей, может оказаться очень полезным при отладке. Это можно включить в EF Core путем вызова EnableSensitiveDataLogging(). Например:

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

Подробные исключения запросов

По соображениям производительности EF Core не упаковывает каждый вызов для чтения значения от поставщика базы данных в блоке try-catch. Однако иногда это приводит к возникновению исключений, которые трудно диагностировать, особенно если база данных возвращает значение NULL, если это не разрешено моделью.

EnableDetailedErrors Включение приведет к тому, что EF вводит эти блоки try-catch и тем самым предоставляет более подробные ошибки. Например:

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

Конфигурация для определенных сообщений

API EF Core ConfigureWarnings позволяет приложениям изменять то, что происходит при обнаружении определенного события. Это можно использовать для следующих способов:

  • Изменение уровня журнала, на котором регистрируется событие
  • Пропустить ведение журнала события полностью
  • Создание исключения при возникновении события

Изменение уровня журнала для события

Иногда это может быть полезно для изменения предварительно определенного уровня журнала для события. Например, это можно использовать для продвижения двух дополнительных событий из LogLevel.DebugLogLevel.Informationследующих:

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

Подавление ведения журнала события

Таким же образом можно отключить отдельное событие из ведения журнала. Это особенно полезно для игнорировать предупреждение, которое было проверено и понято. Например:

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

Создание события

Наконец, EF Core можно настроить для создания данного события. Это особенно полезно для изменения предупреждения в ошибку. (Действительно, это была исходная цель ConfigureWarnings метода, следовательно, имя.) Например:

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

Фильтрация и другая конфигурация

Сведения о фильтрации журналов и другой конфигурации см. в разделе "Ведение журнала в .NET ".

События ведения журнала EF Core определяются одним из следующих вариантов:

  • CoreEventId для событий, общих для всех поставщиков баз данных EF Core
  • RelationalEventId для событий, общих для всех поставщиков реляционных баз данных
  • Аналогичный класс для событий, относящихся к текущему поставщику базы данных. Например, SqlServerEventId для поставщика SQL Server.

Эти определения содержат идентификаторы событий, уровень журнала и категорию для каждого события, как используется Microsoft.Extensions.Logging.