为什么要避免将记录器记录/注入服务？

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 Core日志框架/基类。但是，您始终可以定义自己的记录器界面以在域中使用它，并将其实现为ILogger<T>的包装。

SOLID原则

S 中的 S OLID原则代表SRP（单一责任原则）并且说，一个对象应该只有一个且只有一个责任。在一个对象中执行日志记录和持久性或业务逻辑违反了此原则。

但最终，你必须通过它获得的好处来增加开发成本。如果它是一个长期存在的应用程序（将在未来10年左右使用）和一个复杂的应用程序，作为装饰器记录是有道理的。如果这是一个只有几周开发时间的小项目，这种抽象的好处可能不会超过成本。

Answer 2

如果要记录未处理的异常，您应该添加一个可以处理的中间件。您可以在此SO答案中看到一个示例：https://stackoverflow.com/a/31054664/5795

Answer 3

“最佳实践”是为每个组件注入自己的记录器，让每个组件都进行自己的记录。

如果您认为这对您的应用程序来说太嘈杂，那么您可以更改命名空间部分的详细级别，因此您只能获得控制器的YOUR_APP_KEY级别日志，以及其他所有内容的Information（或更糟）：

Warning

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

3 个答案:

为什么要避免将记录器记录/注入服务？

耦合

SOLID原则