概览

我正在尝试将一些基于 .NET Framework 的项目移植到 .NET Core。这涉及移植大量类库以及使用这些库的顶级控制台/Web 应用程序。

我的部分要求是我的顶级应用程序应该支持基于插件的系统，在该系统中我可以通过引用这些类库的不同子集轻松地交换功能。我已经使用 MEF 来执行此操作。例如，我的一个 ASP.NET Core Web 应用程序涉及通过 ICommunicationService 与设备通信。 ，我有不同的 Nuget 包导出此服务的不同实现:

[Export(typeof(ICommunicationService))]
[Shared]
public sealed class UsbCommunicationService : ICommunicationService
{
}

重新设计类库

目前，这些类库引用Common.Logging并将记录器实例化为只读静态字段:

[Export(typeof(ICommunicationService))]
[Shared]
public sealed class UsbCommunicationService : ICommunicationService
{
    ...
    private static readonly ILog Log = LogManager.GetLogger<UsbCommunicationService>();
    ....
}

我用了Log4Net在我的顶级应用程序中，并通过引用 Common.Logging.Log4Net 在我的类库中促进日志记录适配器。

但是，我知道 ASP.NET Core 依赖于微软新的日志抽象框架 Microsoft.Extensions.Logging并且 ASP.NET Core 应用程序应该设计为通过记录器的构造函数依赖注入(inject)来支持日志记录，如下所示:

public class HomeController : Controller
{
    private ILogger<HomeController> _logger;

    public HomeController(ILogger<HomeController> logger)
    {
        _logger = logger;
    }

    public IActionResult Index()
    {
        _logger.LogInformation("Index action requested at {requestTime}", DateTime.Now);
        return View();
    }
}

我不完全确定在我的新 .NET Core 库和应用程序 ( see this related post ) 中使用哪种日志记录框架组合，但我倾向于从使用 Common.Logging 切换至 Microsoft.Extensions.Logging在我的类(class)图书馆内。在那种情况下，我想知道我应该如何处理记录器的实例化。这样的事情合适吗？

using Microsoft.Extensions.Logging;
...
[ImportingConstructor]
public UsbCommunicationService(
    [Import] IUsbMessageEncoder encoder,
    [Import] IUsbMessageDecoder decoder,
    [Import] ILogger<UsbCommunicationService> logger /* Add this new import */)
{
    ...
}

换句话说，我是否应该将所有需要日志记录的类库切换为在构造期间注入(inject)这些记录器？

使用类库

基于 this answer to a similar question ，我觉得上面详述的方法是正确的。但是，我不确定如何在 ASP.NET Core 应用程序中使用和正确实例化类库中定义的服务。

ASP.NET Core 使用自己的依赖注入(inject)服务，该服务完全独立于 MEF。我不能简单地写类似 services.AddSingleton<ICommunicationService, UsbCommunicationService>(); 的东西在我的网络应用程序中有两个原因:

1. 想法是支持一个基于插件的系统，在该系统中插件是动态发现的，因此不能被“核心”应用程序本身硬引用。

2. UsbCommunicationService 的其他依赖项- IUsbMessageEncoder和 IUsbMessageDecoder - ASP.NET Core 的服务注入(inject)器不知道并且不会被解析。

同样，我无法使用 MEF 获取 UsbCommunicationService 的实例要么因为它无法解析对 ILogger<UsbCommunicationService> 的引用.

总结

简而言之，我正在努力寻找以下解决方案:

• 促进 .NET Core 库中的日志记录，为日志记录提供商提供最大的灵 active 。
• 允许使用依赖注入(inject)将记录器提供给这些类库。
• 允许顶级 ASP.NET Core 或 .NET Core 控制台应用程序在运行时动态地发现和加载这些 .NET Core 库，并为它们提供记录器或记录器工厂，以便顶级应用程序和所有加载的插件使用通用的日志记录提供程序(例如 Serilog、NLog、Log4Net 等)。
  • 例如，如果我想使用 Log4Net 的 ColoredConsoleAppender ，我应该会在同一个控制台中看到所有 ASP.NET 日志和类库日志。

最佳答案

Microsoft.Extensions.Logging 严格来说并不是一个日志框架；这是一个门面。 Debug、Trace、Console 等有内置实现，但这只是为了方便。在实际使用中，您可能会插入类似 Serilog 的东西。 Serilog 实际上是在处理日志记录，而 Microsoft.Extensions.Logging 只是提供了一种抽象的“日志记录”方式，而不必实际使您的应用代码显式依赖于 Serilog 的 API。

Common.Logging 也是一个门面，在这种情况下，您选择插入 log4net 作为实际使用的记录器。然而，这是可以改变的。鉴于此，您可以采取一些可能的途径。

1. 在您的 ASP.NET Core 应用中将 Microsoft.Extensions.Logging 替换为 Common.Logging。是的，你可以做到。就个人而言，我认为 Microsoft.Extensions.Logging 更好，但您可以使用任何您喜欢的东西。

2. 在您的类库中使用 Microsoft.Extensions.Logging 关闭 Common.Logging。如果您无论如何都要重写它们，这可能最有意义，但就代码中需要更改的内容而言，它也涉及最多的摩擦。

3. 为使用 Microsoft.Extensions.Logging 的 Common.Logging 编写适配器。诚然，这有点元，但从技术上讲，简单地使用一个外观与另一个外观一起工作以最终使用特定的日志记录框架并没有错。这就是适配器模式的全部要点。这也让您获得了两全其美的好处:您不需要对您的库或 ASP.NET Core 应用程序进行太多更改。但是，由于多个外观在起作用，它确实会增加代码的熵。虽然不可能说，但我实际上并没有看到 Common.Logging 继续得到维护。既然微软有一种几乎内置的外观，我希望看到它占据主导地位。现在跳船可能是最好的选择，因为您已经进行了一些返工。

关于c# - 在从 ASP.NET Core Web 应用程序调用的动态发现的 .NET Core 类库中注入(inject)记录器的合适模式是什么？，我们在Stack Overflow上找到一个类似的问题： https://stackoverflow.com/questions/39916559/