Реализация библиотеки с открытым исходным кодом: как работать с журналированием?

Question

Я нахожусь в процессе реализации поддержки ведения журнала в библиотеке с открытым исходным кодом, над которой я работаю.Кажется, что большинство сторонних библиотек явно выбирают «предпочтительную» библиотеку журналов, такую ​​как Log4Net или NLog и т. Д., И затем требуют, чтобы потребитель их библиотеки «справился с этим».К счастью, у нас есть библиотека типа Common.Logging для решения этой проблемы в наших приложениях-потребителях, которые объединяют эти реализации ведения журналов библиотек сторонних производителей.

Я собирался попытаться избежать ссылокеще одна сторонняя библиотека из моей собственной библиотеки с открытым исходным кодом, чтобы не вносить еще одну ссылку на сборку в чужое приложение.Возможно, это не проблема, и я должен просто остановиться на этом?

Предполагая, что некоторые люди согласны с тем, что чрезмерные ссылки на сборки раздражают (и поскольку кто-то упомянет об этом), я лично не люблю использовать ILMerge для такого типа ситуаций, так как вы можете легко иметь несколько библиотек, которыеиспользуйте Log4Net, и если каждый из них ILMerged в сборке, это, по моему мнению, просто раздувает размер приложения.

С этой целью я думал о реализации и предоставлении LogBridge, чтобы позволить потребителю моей библиотеки при желании подключаться к моим журналам вызовов (по умолчанию отключено). Также позвольте мне подчеркнуть, что я не говорю о реализации своей собственной структуры ведения журнала, просто гарантирую, что я выставляю ведение журнала, если кто-то заинтересован в его использовании. Я думал, что реализация потребления будет выглядеть примерно так:

public class SomeSetupClass 
{
  private void SomeSetupMethod()
  {
    var log = LogManager.GetLogger("LogSourceName");
    var logBridge = new LogBridge()
                      {
                        DebugEnabled = log.IsDebugEnabled,
                        InformationEnabled = log.IsInfoEnabled,
                        WarningEnabled = log.IsWarnEnabled,
                        ErrorEnabled = log.IsErrorEnabled,
                        CriticalEnabled = log.IsFatalEnabled
                      };

    logBridge.DebugMessageReceived += (sender, e) => log.Debug(e.Message);
    logBridge.InformationMessageReceived += (sender, e) => log.Info(e.Message);
    logBridge.WarningMessageReceived += (sender, e) => log.Warn(e.Message);
    logBridge.ErrorMessageReceived += (sender, e) => log.Error(e.Message);
    logBridge.CrticalMessageReceived += (sender, e) => log.Fatal(e.Message);      }
  }
}

Имеет ли этот подход смысл?Думаю ли я об этом слишком долго, находясь в отпуске, и мне следует просто сослаться на Log4Net или NLog и т. Д. И покончить с этим?Я пропускаю какие-либо основные минусы этого подхода?Имеет ли смысл грубый API?

Как всегда, любопытно, что все думают ...

Обновление

Интересно, если люди думают, что решение jgauffin являетсялучший способ пойти?Я подумал об этом до этого поста;я думал, что LogBridge будет проще подключить для потребителей, чем требовать реализации пользовательского интерфейса в потребляющем проекте?Мысли?

Answer 1

Посмотрите в System.Diagnostics и просто используйте классы Trace или Debug.Такие продукты, как Log4Net, могут подобрать их при необходимости.

Answer 2

Обычно я делаю это:

1. Предоставляем интерфейс для ведения журнала: ILogger
2. Создание фабрики регистратора, используемой для получения регистратора: ILogger _logger = LogManager.GetLogger(typeof(ClassBeingLogged));
3. Предоставьте базовую реализацию, такую ​​как ConsoleLogger.

Вы также можете предоставить примеры в вики проекта, показывающие, как реализовать nlog или log4net.Этого обычно достаточно.

LogManager принимает ILogFactory, который отвечает за создание фактической реализации:

public class LogManager
{ 
    ILogFactory _factory;

    public static void Assign(ILogFactory factory);
    public static ILogger GetLogger(Type typeBeingLogged);
}

public interface ILogFactory
{
    ILogger GetLogger(Type typeBeingLogged);
}

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