C#:ILogger 与静态日志实例

Question

这更像是一个架构问题:您是使用 ILogger(并通过 DI 将其传递到构造函数中)还是更喜欢静态类 Log？

我们经常使用 ILogger，但它似乎确实使代码困惑，尤其是当它通过构造函数传递时。如果不是通过构造函数传递，而是每次都创建，那么我真的看不到使用接口(interface)有什么好处。

那你是怎么处理的呢？我对它背后的论点特别感兴趣 - 而不仅仅是说“静态”或“接口(interface)”。

谢谢

Answer 1

出于不同的原因，使用任何东西的静态实例都是一个坏主意，具体取决于您的用例。
- 它们很难在单元测试中模拟，因此即使不需要它们，您的记录器也会始终写入日志。
- 缺少模拟也意味着您无法编写测试来确保在适当的情况下写入错误日志。- 它们不能在运行时被替换以允许注入(inject)不同的记录器。如果您要发布一个库供其他人使用，这可能很重要。我定义了一个标准的记录器接口(interface)并将所有内容记录到该接口(interface)，然后允许客户端注入(inject)他们自己的记录器，只要它实现了我的接口(interface)。
- 如果您使用供应商提供的默认静态日志实现，您将被锁定在他们的界面中，这意味着您无法隐藏或更改记录器的表面区域。如果新记录器的语法发生变化，则更改记录器需要付出更大的努力。

因此，您需要进行某种注入(inject)。就个人而言，我更喜欢在构造函数中包含所有依赖项，即使它变得冗长，因为很容易看到特定类具有的所有依赖项。如果你想避免一个大的构造函数，你可以看看属性注入(inject)。这需要类属性的属性，但仍然为您提供注入(inject)依赖项的所有优势。如果将注入(inject)的属性放在基类上，它将自动对所有子类可用。

顺便说一句，我不是上面描述的 Ambient Context 的粉丝，因为它基本上是一个单一用途的 DI 容器，你必须有一个对多个环境服务容器的具体引用。如果这种模式的轻松访问对您有吸引力，请查看 Service Location，它的想法相同但更灵活。