通过 .NET 架构测试在公共存储库方法中强制执行 Serilog 日志记录

Question

在 .NET 8 Web API 应用程序中，如何利用 NetArchTest.Rules 进行架构测试来确保存储库类中的每个公共方法都利用 Serilog 的 Information 方法进行日志记录？目标是记录方法入口点和出口点以及相关详细信息。

这是我在这种情况下寻找的东西：

1. 每个公共存储库方法都使用以下方式启动日志记录 _logger.Information() 在开头。
2. 每个方法都使用 _logger.Information() 记录其完成情况 结束。
3. 记录消息应包含有关 被调用的方法以及任何相关参数或结果。

代码：

using Serilog;

namespace Demo.Repository;

public interface IProductRepository
{
    IEnumerable<Product> GetAllProducts();
    Product GetProductById(int id);
    // ... other methods
}

public class ProductRepository : IProductRepository
{
    private readonly ILogger<ProductRepository> _logger;

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

    public IEnumerable<Product> GetAllProducts()
    {
        _logger.Information("GetAllProducts method invoked.");
        // Implement product retrieval logic
        var products = // ... retrieve products
        _logger.Information("Retrieved {0} products.", products.Count());
        return products;
    }

    public Product GetProductById(int id)
    {
        _logger.Information("GetProductById method invoked for id: {0}.", id);
        // Implement product retrieval logic by id
        var product = // ... retrieve product
        _logger.Information("Product with id {0} {1} retrieved.", id, product?.Name ?? "not found");
        return product;
    }

    // ... other methods
}

任何人都可以通过提供指导来帮助我吗

Answer 1

查看该库的文档和源代码，它似乎纯粹基于反射：查看类型和方法签名。您可以使用它来确保存储库类依赖于

ILogger<>

，但除此之外您将无法使用它。

如果您认为值得花时间采用这种方法，那么您的前两个要求应该可以通过“自定义代码分析器”来强制执行。根据您对“有意义”的定义，第三个要求可能几乎不可能用当前技术来执行。 如果你想变得超级规范，你可能会找到其他创造性的方法来鼓励或强制你正在寻找的行为。例如：

您可以创建一个自定义帮助器接口/实现，标准化您期望记录的信息类型（ID、计数、名称等），并确保它以您认为应该具有的格式记录。这允许您一次对所有存储库日志记录进行彻底更改（例如添加属性、更改日志记录框架、更改日志级别），而无需更改每个存储库中的代码。

• 您可以强制存储库接口的依赖注入包含一个日志装饰器——一个唯一目的是记录输入和输出的类。如果有人必须编写日志记录装饰器方法的实现只是为了构建代码，那么他们就必须不遗余力地不向其中添加日志记录代码。并且可以对业务逻辑进行单元测试，而无需模拟记录器。
• 使用像 Fody 这样的框架，您可以编写或配置自动添加日志记录代码的 IL Weaver，因此开发人员甚至不必考虑每个存储库。
话虽如此，我质疑您所设定的执行水平是否明智。如果您没有将您的实践与变革的原因紧密结合起来，那么您就会冒着阻碍而不是推广良好实践的风险。考虑：

记录所有内容会产生高信噪比，这可能会使常见情况下的调试变得更加困难。此类数据多久能真正用于追踪错误？

• 如果您的公司决定根据未来推出的新框架和工具来改变其实践，您将拥有大量可能需要迁移的日志记录代码。
• 如果某些存储库处理不应记录的敏感数据，您可能会面临违反隐私法或安全合规性的风险。
• 开发人员是否会找到疯狂的解决方法，例如将存储库放在新位置以避免在某些情况下必须登录？
• 要求开发人员在
Count()
• 上记录

  IEnumerable<>

  是否会导致数据库的额外往返成本高昂？
传授良好的原则并将实施细节（例如诊断日志记录）留给开发人员自行决定，而不是过于规范，通常会更好。