问题描述
上下文
我已经在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.Error 与 log.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的回购中：
You might be interested in reading this issue on Serilog's repo:
I在我所有的项目中都亲自使用Serilog的 ILogger 不仅是因为我更喜欢较短的方法名，还因为我更喜欢 not 在其中插入记录器每个类的每个构造函数，并且，在解决问题时非常有用。例如，
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>();
// ...
}
但是，如果您正在开发库，我建议您使用Microsoft的通用 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 是线程安全的，因此在您进行操作时注册为单例如果您希望所有类共享同一个实例，则上述方法是正确的（）-没错。
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接口？的文章就介绍到这了，希望我们推荐的答案对大家有所帮助，也希望大家多多支持！