记录器包装器最佳实践

Posted 2023-02-26

【中文标题】记录器包装器最佳实践

【英文标题】：Logger wrapper best practice

【发布时间】：2011-08-04 13:06:30

【问题描述】：

我想在我的应用程序中使用 nlogger，也许将来我需要更改日志系统。 所以我想使用日志外观。

您知道如何编写现有示例的任何建议吗？ 或者只是给我这个领域的一些最佳实践的链接。

【问题讨论】：

已经存在：netcommon.sourceforge.net

你签出The Simple Logging Facade project on Codeplex了吗？

相关：***.com/questions/9892137/…

【参考方案1】：

我曾经使用诸如Common.Logging 之类的日志记录外观（甚至隐藏我自己的CuttingEdge.Logging 库），但现在我使用Dependency Injection pattern。这允许我将记录器隐藏在应用程序定义的抽象后面，该抽象遵循Dependency Inversion Principle 和Interface Segregation Principle (ISP)，因为它有一个成员，并且接口是由我的应用程序定义的；不是外部库。

尽量减少应用程序核心部分对外部库存在的了解，越好；即使您无意更换您的日志库。对外部库的硬依赖使测试代码变得更加困难，并且使用从未专门为您的应用程序设计的 API 使您的应用程序变得复杂。

这是我的应用程序中的抽象通常看起来的样子：

public interface ILogger

    void Log(LogEntry entry);


public sealed class ConsoleLogger : ILogger

    public void Log(LogEntry entry)


public enum LoggingEventType  Debug, Information, Warning, Error, Fatal ;

// Immutable DTO that contains the log information.
public struct LogEntry

    public LoggingEventType Severity  get; 
    public string Message  get; 
    public Exception Exception  get; 

    public LogEntry(LoggingEventType severity, string msg, Exception ex = null)
    
        if (msg is null) throw new ArgumentNullException("msg");
        if (msg == string.Empty) throw new ArgumentException("empty", "msg");

        this.Severity = severity;
        this.Message = msg;
        this.Exception = ex;
    

可选地，可以使用一些简单的扩展方法来扩展此抽象（允许接口保持狭窄并继续遵守 ISP）。这使得该接口的消费者的代码更加简单：

public static class LoggerExtensions

    public static void Log(this ILogger logger, string message) =>
        logger.Log(new LogEntry(LoggingEventType.Information, message));

    public static void Log(this ILogger logger, Exception ex) =>
        logger.Log(new LogEntry(LoggingEventType.Error, ex.Message, ex));

    // More methods here.

因为接口只包含一个方法，所以很容易创建一个ILogger 实现，proxies to log4net、to Serilog、Microsoft.Extensions.Logging、NLog 或任何其他日志库，并配置您的 DI 容器以将其注入在其构造函数中具有ILogger 的类。创建写入控制台的实现或可用于单元测试的假实现也很容易，如下面的清单所示：

public class ConsoleLogger : ILogger

    public void Log(LogEntry entry) => Console.WriteLine(
      $"[entry.Severity] DateTime.Now entry.Message entry.Exception");


public class FakeLogger : List<LogEntry>, ILogger

    public void Log(LogEntry entry) => this.Add(entry);

在具有单个方法的接口之上具有静态扩展方法与具有多个成员的接口完全不同。扩展方法只是创建LogEntry 消息并通过ILogger 接口上的唯一方法传递它的辅助方法。这些扩展方法本身不包含自身的易失性行为，因此不会妨碍可测试性。如果您愿意，您可以轻松地测试它们，它们会成为消费者代码的一部分；不是抽象的一部分。

这不仅允许扩展方法在不需要更改抽象的情况下发展，扩展方法和LogEntry 构造函数在使用记录器抽象时始终执行，即使该记录器被存根/模拟。当在测试套件中运行时，这可以更加确定对记录器的调用的正确性。我已经为此多次开枪打死自己，在我的单元测试期间我对使用的第三方记录器抽象的调用成功，但在生产中执行时仍然失败。

单成员接口也使测试变得更加容易；具有许多成员的抽象使得很难创建实现（例如模拟、适配器和装饰器）。

当您这样做时，几乎不需要日志外观（或任何其他库）可能提供的某些静态抽象。

尽管如此，即使使用这种ILogger 设计，您也更喜欢以只有少数类需要依赖于您的ILogger 抽象的方式来设计您的应用程序。 This answer详细讲了这个。

【讨论】：

@GabrielEspinoza：这完全取决于您放置扩展方法的命名空间。如果您将其放置在与接口相同的命名空间或项目的根命名空间中，则问题将不存在。

@user1829319 这只是一个例子。我相信您可以根据此答案提出适合您特定需求的实现。

我还是不明白...拥有 5 种 Logger 方法作为 ILogger 的扩展而不是 ILogger 的成员的优势在哪里？

@Elisabeth 好处是您可以使外观接口适应任何日志框架，只需实现一个函数：“ILogger::Log”。扩展方法确保我们可以访问“便利”API（例如“LogError”、“LogWarning”等），无论您决定使用哪个框架。尽管使用 C# 接口，但这是一种添加通用“基类”功能的迂回方式。

我需要再次强调这很棒的原因。将您的代码从 DotNetFramework 上转换为 DotNetCore。我做这个的项目，我只需要写一个新的混凝土。我没有的那些......我很高兴我找到了这条“回来的路”。

【参考方案2】：

我使用了https://github.com/uhaciogullari/NLog.Interface的小型接口包装器+适配器，也就是available via NuGet：

PM> Install-Package NLog.Interface 

【讨论】：

v4.0的NLog库中有一个ILogger接口。你不再需要这个库了

【参考方案3】：

到目前为止，最好的办法是使用 Microsoft.Extensions.Logging 包 (as pointed out by Julian)。大多数日志框架都可以与此一起使用。

定义您自己的界面，如Steven's answer 中所述，对于简单的情况是可以的，但它遗漏了一些我认为重要的事情：

结构化日志记录和解构对象（Serilog 和 NLog 中的 @ 表示法） 延迟的字符串构造/格式化：因为它需要一个字符串，所以它必须在调用时评估/格式化所有内容，即使最终由于低于阈值而不会记录事件（性能成本，请参阅前一点） 出于性能原因，您可能需要像 IsEnabled(LogLevel) 这样的条件检查

您可能可以在自己的抽象中实现所有这些，但那时您将重新发明***。

【参考方案4】：

LibLog 项目的形式出现了一个很好的解决方案。

LibLog 是一个日志抽象，内置支持主要记录器，包括 Serilog、NLog、Log4net 和企业记录器。它通过 NuGet 包管理器作为源 (.cs) 文件而不是 .dll 引用安装到目标库中。这种方法允许在不强制库承担外部依赖的情况下包含日志记录抽象。它还允许库作者在不强制使用应用程序显式向库提供记录器的情况下包含日志记录。 LibLog 使用反射来确定正在使用的具体记录器，并在库项目中无需任何明确的接线代码即可将其连接起来。

因此，LibLog 是在库项目中进行日志记录的绝佳解决方案。只需在您的主应用程序或服务中引用并配置一个具体的记录器（Serilog for win），然后将 LibLog 添加到您的库中！

【讨论】：

我已经使用它来解决 log4net 重大更改问题 (yuck) (wiktorzychla.com/2012/03/pathetic-breaking-change-between.html) 如果您从 nuget 获得此信息，它实际上会在您的代码中创建一个 .cs 文件，而不是添加对预编译 dll 的引用。 .cs 文件被命名为您的项目。所以如果你有不同的层（csprojs），你要么有多个版本，要么你需要合并到一个共享的csproj。当您尝试使用它时，您会发现这一点。但就像我说的，这是 log4net 重大变更问题的救命稻草。

【参考方案5】：

一般我更喜欢创建一个类似的界面

public interface ILogger

 void LogInformation(string msg);
 void LogError(string error);

在运行时我注入了一个从这个接口实现的具体类。

【讨论】：

比起@Steven 的回答，我更喜欢这个。他引入了对LogEntry 的依赖，从而引入了对LoggingEventType 的依赖。 ILogger 实现必须处理这些LoggingEventTypes，可能虽然case/switch 是code smell。为什么要隐藏 LoggingEventTypes 依赖项？实现必须无论如何处理日志级别，因此最好显式了解实现应该做什么，而不是将其隐藏在具有一般参数的单个方法后面。

作为一个极端的例子，想象一个ICommand，它有一个Handle，它接受一个object。实现必须case/switch 超过可能的类型才能履行接口的合同。这并不理想。不要有一个抽象来隐藏无论如何都必须处理的依赖项。取而代之的是一个明确说明预期内容的界面：“我希望所有记录器都能处理警告、错误、致命等”。这比“我希望所有记录器都能处理消息，其中包括警告、错误、致命等”更可取。

我有点同意@Steven 和@DharmaTurtle。除了 LoggingEventType 应该被称为 LoggingEventLevel 因为类型是类并且应该在 OOP 中这样编码。对我来说，不使用接口方法与不使用接口方法没有区别。不使用相应的enum 值。而是使用ErrorLoggger : ILogger、InformationLogger : ILogger，每个记录器都定义了它自己的级别。然后 DI 需要注入所需的记录器，可能通过一个键（枚举），但这个键不再是接口的一部分。 （你现在是 SOLID）。

@Wouter 我不会打折 SOLID，但你必须务实，因为编程没有普遍的真理，只能使用不同的设计进行权衡。但是您将如何在运行时使用您的示例/设计切换日志记录级别，这在例如Nlog、log4net 等？

@Jesper loglevel 是具体的 ILogger 类型，记录器是启用还是禁用。记录器可以共享基于 logLevelValue 启用或禁用的配置。现在，如果记录器共享一个通用配置模型，您可以根据名称和值启用或禁用记录器，类似于 log4net。

【参考方案6】：

您可以使用Castle Logging Services 或Simple Logging Façade，而不是编写自己的外观。

两者都包括 NLog 和 Log4net 的适配器。

【参考方案7】：

自 2015 年起，如果您正在构建 .NET 核心应用程序，您也可以使用 .NET Core Logging。

NLog 挂接的包是：

NLog.Web.AspNetCore 供 ASP.NET Core 用户使用 NLog.Extensions.Logging 适用于 .NET Core 用户，例如控制台项目