Журнал сообщений из библиотеки классов .NET Standard - PullRequest
Новая
       37

Журнал сообщений из библиотеки классов .NET Standard

0 голосов
/ 18 ноября 2018

У меня есть решение с проектом ASP.NET Core (2.1.5) Web API, которое ссылается на несколько проектов библиотек классов .NET Standard 2.0.

Я хочу реализовать некоторую регистрацию в своем приложении, и я уже сделал это для проекта Web API, используя NLog (фактически это может быть любой поставщик, реализующий ILogger). Для этого я определил в Program.cs статическое поле, которое инициализируется во время выполнения и настраивается с использованием WebHostBuilderExtensions.ConfigureLogging : 

using Microsoft.Extensions.Logging;

public class Program
{
    private static readonly Logger logger = NLogBuilder.ConfigureNLog("NLog.config").GetCurrentClassLogger();
    // other content ...
}

public static IWebHostBuilder CreateWebHostBuilder(string[] args)
{
    var webHost = WebHost.CreateDefaultBuilder(args)
        .UseStartup(typeof(Startup).GetTypeInfo().Assembly.FullName)
        .ConfigureLogging(builder =>
        {
            builder.ClearProviders();
            builder.SetMinimumLevel(LogLevel.Information);
        })
        .UseNLog();
    // other content ...
}

Это позволяет мне использовать DI ILogging в каждом классе в моем приложении ASP.NET Core всякий раз, когда мне это нужно: 

using Microsoft.Extensions.Logging;

public class Startup
{
    public IConfiguration Configuration { get; }
    private readonly ILogger<Startup> _logger;

    public Startup(IConfiguration configuration, ILogger<Startup> logger)
    {
        Configuration = configuration;
        _logger = logger;
    }
}

Но теперь я полностью запутался в настройке ведения журнала для моих библиотек классов. Один из вариантов, который я могу себе представить, - это использовать механизм DI, чтобы мои библиотеки могли вызывать один и тот же ILogger интерфейс, подобный этому: 

using Microsoft.Extensions.Logging;

public class MyLibraryClass
{
    private ILogger<MyLibraryClass> _logger;

    public MyLibraryClass(ILogger<MyLibraryClass> logger)
    {
        _logger = logger;
    }

    public void SomeLibraryMethod()
    {
        _logger.LogInformation("Some library method logging here...);
    }
}

Но это выглядит довольно неловко, так как мне нужно внедрить эту зависимость для всех моих библиотечных классов, где мне нужно ведение журнала (так сказать, для всех классов).

Я также думаю о некотором статическом классе для каждого библиотечного проекта, в котором эта зависимость вводится только один раз, так что статический класс может выступать в качестве оболочки для ILogger . Или даже перенести NLog из проекта WebAPI в одну из библиотек (или даже создать отдельную библиотеку) и использовать его для вызова этой библиотеки из всех других проектов. Но, как рекомендовано здесь , лучше иметь отдельный экземпляр ILogger для каждого класса для фильтрации разных регистраторов. Или может быть достаточно создать статические регистраторы для определенного проекта?

Мое другое беспокойство заключается в том, что такие статические оболочки вокруг ILogger потребовали бы от меня определить мой собственный интерфейс для работы с сообщениями журнала. Но ILogger - это хорошо продуманный интерфейс, и такое отношение, похоже, является своего рода двойной работой.

Я просмотрел множество пошаговых руководств, но большинство из них описывает, как настроить ведение журнала только для одного веб-приложения ASP.NET Core (или, скорее всего, я использовал неправильные ключевые слова для поиска). В любом случае, я застрял в этот момент и не знаю, как правильно заставить мои библиотеки использовать тот же поставщик журналов и файл, что и для моего основного приложения WebAPI. Может быть, есть какие-то известные практики, которые я пропустил?

1 Ответ

0 голосов
/ 18 ноября 2018

Я не думаю, что это неудобно Microsoft.Extensions.Logging.ILogger - это общий интерфейс, который реализуется большинством библиотек журналов.

Использование синглтона в этом сценарии привязало бы вас к определенной библиотеке журналов, которая может подойти для небольшого проекта.или проекты POC, но представьте, что вы делитесь своей библиотекой между командами или публикуете ее.Намного удобнее ожидать интерфейс.

Что касается того, как добавить выбранную библиотеку журналов в библиотеку классов, вам не нужно об этом беспокоиться, поскольку об этом заботится система DI.

Выпросто нужно объявить ваш класс как зависимость конструктора в одном из классов вашего веб-проекта.

...