记录层中异常的ASP.NET 5最佳实践

Question

我有一个使用ASP.NET 5和MVC 6的项目。

• 我的表示层
• 我的域模型层
• 我的基础设施层
• 我的业务逻辑层
• 以及我的数据访问层。

目前，我使用依赖注入在控制器方法中记录异常。

private readonly ILogger<CustomerController> _logger;
public CustomerController(ILogger<CustomerController> logger)
{
     _logger = logger;
}

public bool TestLog()
{
     _logger.LogError((int)LoggingEvents.LIST_ITEMS, "Test info #543434");
     return true;
}

在我的其他层(如数据访问层)中使用记录器的最佳实践是什么？

Answer 1

最好是只在应用程序层(控制器、应用程序服务--而不是域服务)中使用ILogger<T>。

如果您想在域服务/存储库周围添加日志记录，最好为其创建装饰器。只有当您将接口从它们的实现中抽象出来并在任何地方使用/注入接口时，这才能很好地工作。

然而，对装饰师所能做的事情是有限制的。可以在调用公共接口中定义的方法之前和之后进行日志记录。不是在电话里。

为什么要避免将日志记录/注入到服务中？

耦合

您应该避免在域对象中注入ILogger<T>，因为这会将您的域耦合到ASP.NET核心日志框架/基类。但是，您始终可以定义自己的记录器接口，以便在域中使用它，并将其实现为围绕ILogger<T>的包装器。

固体原理

S in SOLID原则代表SRP (单责任原则)，并表示一个对象应该只有一个和唯一一个责任。对一个对象执行日志记录和持久化或业务逻辑违反了这一原则。

但最终，你必须用你从中获得的好处来权衡开发的成本。如果它是一个长期存在的应用程序(将用于未来10年左右)和一个复杂的应用程序，作为装饰者登录是有意义的。如果它是一个小项目，只有几周的开发时间，这种抽象的好处可能不会超过成本。

Answer 2

“最佳实践”是只为每个组件注入自己的记录器，并让每个组件执行自己的日志记录。

如果您认为这对您的应用程序来说太吵了，那么您可以更改名称空间部件的详细级别，因此您只能获得控制器的Information级别日志，以及其他所有内容的Warning (或更糟的)：

loggerFactory.AddConsole(new ConsoleLoggerSettings()
{
    Switches = new Dictionary<string, LogLevel>()
    {
        ["MyNamespace.Services"] = LogLevel.Warning,
        ["MyNamsepace.Controllers"] = LogLevel.Information
    }
});

Answer 3

如果您想记录未处理的异常，您可能应该添加一个可以处理这些异常的中间件。您可以在这个例子中看到一个例子，所以答案是：https://stackoverflow.com/a/31054664/5795