模式使用Serilog(通过ILogger vs使用静态Serilog.Log)

tym*_*tam 9 c# serilog

背景

Serilog被选为记录器的新项目中,我自动开始绕过ILogger界面.代码访问Log.Logger一次,从那时起,希望日志记录的类ILogger通过构造函数注入接受.

我受到了这种做法的挑战,建议是在Log课堂上使用静态方法,例如Serilog.Log.Debug(...).这个论点是,有一set;Log.Logger如此嘲讽是很容易.

看看api,我可以看到传递的好处之一ILogger就是ForContext方法.

我花了一些时间在网上和Serilog的文档中,但是我找不到有关在整个应用程序代码中访问日志的规范方法的信息.

是否存在规范的,即大多数情况下更好的方式来访问/传递Serilog记录器,如果存在,是否ILoggerSerilog.Log类上传递或使用静态API ?

Rub*_*ink 5

还有一个ForContextLog.Logger,所以我不会在此基础上决定.如果您正在进行模拟/测试日志记录,您不希望通过全局实例执行此操作 - 任何以这种方式进行日志记录的库代码都需要ILogger输入,允许调用者检测和/或通过在Log.Logger他们认为合适的.如果你不这样做,测试永远不会并行运行,这是一个很大的放弃.

对我来说,主要的权衡实际上是你是否愿意使用Enrich.FromLogContextLogContext.*接口,这些接口会挂掉.NET ExecutionContext,你需要小心不要疯狂.(是的,可以说你可以使用一个收集器隔离ExecutionContext我的前一点,但是甚至不去那里.)

根据你的DI的操作方式,你可能想要ILogger<T>输入你的输入,但是再次,除非有人需要能够使用仪器来获取信息,static ILogger _logger = Log.ForContext<MyClass>()只要有Log足够的时间连接就可以了.

  • Enrich.FromLogContext 功能强大,不容回避 - 它扮演着非常重要的角色,并且可以很好地扩展。我的警告只是为了劝阻您不要尝试编写使用/滥用“E.FLC”作为处理并行性的方法的测试——虽然这可以起作用,但它不必要地令人费解并且完全可以避免。在不需要考虑日志记录的情况下,使用 E.FLC 和静态记录器是完全合理的。(另外,如果有陷阱,请编写您自己的 ILogSink,除非您是真正的 RX-fiend,否则不要在 observable sink 等问题上胡思乱想) (2认同)