.net - 如果使用日志门面，在使用 IoC/DI 时是否应该注入(inject)日志基础设施？

Question

我正在使用 Autofac 作为我的 IoC，并且从我读过的关于 DI 主题的所有内容中，我教会了使用“构造函数注入(inject)”来显式公开类依赖项......
但是，我也在使用 Log4Net 的日志外观(Common.Logging)，并创建了 Autofac 模块来注入(inject)它。
现在，在我想做一些日志记录的每个类中，我都有额外的构造函数参数(参见示例 #1)....

我想知道在使用日志记录外观时是否需要记录 DI？
我知道通过构造函数签名显式暴露依赖项是一个很好的架构。
但在记录外观的情况下，我相信以下是正确的:

我仍然可以随时“换掉”日志框架

恕我直言，该类并不真正依赖于 Logger。如果未配置日志记录，则使用 NullLogger。这几乎是“如果你需要它就可以”与“除非你提供它否则它将无法工作”的交易......(参见示例＃2)

那么，其他人怎么看？注入(inject)日志外观是不是矫枉过正？
有一些similar questions关于这个主题，但更笼统地说(infrastructure) - 我主要对日志记录感兴趣....

// IoC "way"
public class MyController : BaseController
{
    private readonly ILog _logger;

    public MyController(ILog logger)
    {
        _logger = logger;
    }

    public IList<Customers> Get()
    {
        _logger.Debug("I am injected via constructor using some IoC!");
    }
}

// just use the logger "way"
public class MyController : BaseController
{
    private static readonly ILog Logger = LogManager.GetCurrentClassLogger();

    public IList<Customers> Get()
    {
        Logger.Debug("Done! I can use it!");
    }
}

Answer 1

这可能是一个较旧的帖子，但我想插话。
认为日志系统的 IoC 过于矫枉过正的想法是短视的。
日志是一种机制，应用程序开发人员可以通过它与其他系统(事件日志、平面文件、数据库等)进行通信，而这些东西现在都是应用程序所依赖的外部资源。
如果我的单元测试代码现在锁定到特定的记录器，我应该如何对组件的日志记录进行单元测试？分布式系统通常使用记录器来集中源，而不是文件系统上的平面文件。
对我来说，注入(inject)记录器与注入(inject)数据库连接 API 或外部 Web 服务没有什么不同。它是应用程序需要的资源，因此应该注入(inject)，因此您可以测试组件对所述资源的使用情况模拟所述依赖关系的能力，以独立于日志记录接收者测试我的组件的输出，对于强大至关重要单元测试。
并且鉴于 IoC 容器使这种注入(inject)成为 child 的游戏，在我看来，不使用 IoC 来注入(inject)记录器并不比这样做更有效。