ASP.NET Core 中的 Serilog DI,要注入哪个 ILogger 接口? [英] Serilog DI in ASP.NET Core, which ILogger interface to inject?

查看:32
本文介绍了ASP.NET Core 中的 Serilog DI,要注入哪个 ILogger 接口?的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

背景

我已经在我的 ASP.NET Core 应用程序中成功配置了 Serilog,只剩下 DI 部分.

I've successfully configured Serilog in my ASP.NET Core application, only the DI part remains.

问题

现在我有两个 ILogger 接口,一个是 Serilog.ILogger,另一个是 Microsoft.Extensions.Logging.ILogger.两者都基于我的 Serilog 配置工作,但我不知道该使用哪个?(我的意思是,在 Serilog 配置到位后 Microsoft.Extensions.Logging.ILogger 也正确地通过 Serilog 登录,所以我的配置很荣幸)

Now I have two ILogger interfaces, one is Serilog.ILogger the other is Microsoft.Extensions.Logging.ILogger. Both works based on my Serilog config, and I do not know which to use? (I mean, after Serilog config in place Microsoft.Extensions.Logging.ILogger also correctly logging through Serilog, so my config is honored)

如果 Microsoft.Extensions.Logging.ILogger 我知道如何配置 DI 使其工作.但是,在 Serilog.ILogger 的情况下,我看到 Serilog 有一个静态 Log.Logger 实例(可能是单例)

In case Microsoft.Extensions.Logging.ILogger I do know how to configure DI to make it work. However in case of Serilog.ILogger I see that Serilog has a static Log.Logger instance (probably a singleton)

我不想在我的代码中使用这个静态属性,主要是为了测试的原因,所以我想构造函数注入它.解决方案是:

I do not want to use this static property in my code, mainly for testing reasons, so I would like to to constructor inject it. The solution would be:

services.AddSingleton(Log.Logger); // Log.Logger is a singleton anyway

..但是当许多多个线程将同时使用这个非常相同的实例时,我担心 Web 应用程序中的这个单例.它是线程安全的吗?如果不是,那么将 Serilog.ILogger 与 DI 一起使用的解决方案是什么?

..but I am concerning about this singleton in a Web Application when many multiple threads will use this very same instance concurrently. Is it thread safe? If it is not, then what would be the solution to use Serilog.ILogger with DI?

推荐答案

选择在您的应用程序中使用哪个界面是一个品味问题,真的.如果您更喜欢 Serilog 的 ILogger 较短的方法名称(例如 log.Errorlog.LogError),请使用它,否则使用 Microsoft 的通用 <代码>ILogger<>.您可以控制在自己的项目中使用的所有依赖项,因此没有强有力的技术理由偏爱其中一个.

Choosing which interface to use within your application is a matter of taste, really. If you prefer Serilog's ILogger shorter method names (e.g. log.Error vs log.LogError), go with that, otherwise use the Microsoft's generic ILogger<>. You have control over all the dependencies you use in your own projects, so there's no strong technical reason to prefer one over the other.

您可能有兴趣在 Serilog 的 repo 上阅读此问题:

You might be interested in reading this issue on Serilog's repo:

我应该使用 Microsoft.Extensions.Logging.ILogger 还是 Serilog.ILogger?.

我个人在我所有的项目中都使用 Serilog 的 ILogger,不仅因为我更喜欢较短的方法名称,还因为我更喜欢在每个项目中注入记录器每个类的构造函数,也很容易有一个 上下文记录器每个类都使用 Log.ForContext<>,这在解决问题时很有用.例如

I personally use Serilog's ILogger across all my projects not only because I do prefer the shorter method names, but also because I prefer not to inject a logger in every single constructor of every class, and it's also easy to have a contextual logger for every class using Log.ForContext<>, which is useful when troubleshooting issues. E.g.

public class SomeService
{
    private readonly ILogger _log = Log.ForContext<SomeService>();
    // ...
}

public class SomeRepository
{
    private readonly ILogger _log = Log.ForContext<SomeRepository>();
    // ...
}

<小时>

如果你正在开发一个库,当然我建议你使用微软的通用ILogger<>,而不是依赖于Serilog 并强制您的库的使用者也依赖于 Serilog.


If you were developing a library though, I'd recommend using Microsoft's generic ILogger<>, of course, instead of taking a dependency on Serilog and force consumers of your library to also take a dependency on Serilog.

Log.Logger 是线程安全的,因此如果您希望所有类共享同一个实例(没有 SourceContexts) - 没有错.

Log.Logger is thread-safe, thus registering as a singleton as you are doing above is correct if you want all classes to share the same instance (without SourceContexts) - nothing wrong with that.

这篇关于ASP.NET Core 中的 Serilog DI,要注入哪个 ILogger 接口?的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆