为什么Logging不使用字符串插值

Question

我一直在关注Logging in ASP.NET Core 哪个工作得很好.

我对这一行有疑问

_logger.LogWarning(LoggingEvents.GetItemNotFound, "GetById({ID}) NOT FOUND", id);

我想知道为什么他们不使用$ - 字符串插值？

_logger.LogWarning(LoggingEvents.GetItemNotFound, $"GetById({ID}) NOT FOUND");

为什么LogWarning扩展会有一个params object[] args参数？

什么时候你可以发送字符串消息中的所有内容.

我认为这是有原因的,但我无法在任何地方找到解释.我想知道我应该使用哪种方法才能正确登录.net核心.

Answer 1

我知道这已经有 4 年历史了，但我觉得所提供的任何答案都不是真正正确的。

原因是结构化日志记录，如果您使用字符串插值，您只是记录单个字符串，而使用结构化日志记录，您将单独记录变量，以便更轻松地访问它们。

想象一下，您有一个网站，并且想要提醒或提供有关页面加载时间的报告。你像这样记录logger.LogDebug($"{PageName} took {ms}ms to load.");你的日志可以包含的内容是"Index took 53ms to load."

如果您像这样记录它，logger.LogDebug("{PageName} took {ms}ms to laod.", PageName, sw.ElapsedMilliseconds);那么根据您的日志记录提供程序，您可以单独访问所有属性并按 PageName 轻松分组，并过滤​​所有超过 50 毫秒的加载时间。无需恢复到正则表达式。例如SELECT PageName, Count(*) FROM Logs WHERE LogText = '{PageName} took {ms}ms to load.' and ms > 50 GROUP BY PageName

Answer 2

至少有两个原因.

首先,记录前置字符串插值,而微软尚未发明时间机器.字符串插值仅在2015年7月的C#6中引入,但日志记录方法遵循Microsoft.Build.Utilities自dotnet framework 2.0以来使用的相同模式.

第二,表现.如果使用字符串插值并将字符串作为参数传递,则在调用之前完成插值Log.但是,并非每次调用Log都会导致记录某些内容 - 这取决于配置.

如果您在DEBUG级别上记录某些内容并且当前配置是针对INFORMATION级别的,那么进行字符串插值是浪费时间,您只需说"谢谢,但不要谢谢",并在对参数执行任何操作后立即返回.

扩展第二,性能在内部,大多数记录器看起来基本上是这样的:

void LogDebug(string Message, params object[] args){
    if(this.DebugEnabled){
        Log.Write(string.Format(Message,args)); 
    }
}

// 1 with parameters
LogDebug("GetById({ID}) NOT FOUND", id);
// 2 interpolated
LogDebug($"GetById({id}) NOT FOUND");

因此,如果未启用Debug,则会减少一次插值操作.

Answer 3

我怀疑这个问题可以改写为：

他们为什么不提供接受FormattableString的重载，以使用字符串插值语法传递消息模板和参数，就像EF Core用于参数化查询一样？

我会说他们做对了。在这一点上，使用FormattableString带来的好处很小，但会造成很多混乱。

我只是发现Serilog的作者解释了为什么即使语义记录库看起来很适合这种情况，这也不是一个好主意

语义记录

可以说这FormattableString将是对Serilog之类的语义日志记录库的巨大补充。在这种情况下，内插字符串确实会丢失重要信息。

通话

Log.Information("Logged in {UserId}", loggedInUserId);

不仅会基于模板记录字符串，还会保留参数的名称和值，并将其提供给过滤器和目标。取得相同的结果不是很好：

Log.Information($"Logged in {loggedInUserId}");

Serilog的作者不这么认为，并解释说：

1. 好的变量名不一定是好的属性名
2. 孔并不总是具有明显的名称，例如 Log.Information($"Enabling categories {new[]{1, 2, 3}}");

并得出结论

字符串插值是一个很棒的功能，我很期待C＃很久了。为Serilog提供直接支持的想法非常有趣，值得探讨，但是我越来越相信这是不必要的。

当插值保持代码DRY时，插值会很不错，这样可以消除{0}和{1}的多余杂波并防止参数不匹配。

对于Serilog，我认为将{UserId}之类的属性名称视为冗余是不正确的。在实施良好的日志记录策略中，它们是图片中非常重要的一部分，值得自己考虑。您不会让变量名确定关系数据库中的表名和列名–在这里要考虑的折衷点是完全相同的。

原始说明

这实际上是EF Core最具争议的功能之一，很容易导致人们希望通过使用参数避免的SQL注入和转换问题。

这个电话：

string city = "London";
var londonCustomers = context.Customers
    .FromSql($"SELECT * FROM Customers WHERE City = {city}");

调用FromSql(FormattableString)并将创建一个参数化查询：

SELECT * FROM Customers WHERE City = @p0

并London作为参数值传递。

另一方面：

string city = "London";
var query=$"SELECT * FROM Customers WHERE City = {city}";
var londonCustomers = context.Customers.FromSql(query);

呼叫，FromSql(string)并会产生：

SELECT * FROM Customers WHERE City = London

哪个无效。即使您确实知道这种风险，也常常陷入这种陷阱。

当您已经有了预定义的查询或消息时，它根本没有帮助。这种用法在日志记录中更为常见，在日志记录中，您（应该）使用在众所周知的位置定义的特定消息模板，而不是在每个日志位置都散布相似的外观字符串。

有人可能会说，这种添加使EF Core 2.0更加安全，因为人们已经开始在EF Core 1.0中使用字符串插值，从而导致无效查询。FormattableStringEF Core团队增加了超负荷的能力，从而减轻了这种情况，同时更容易意外导致其他问题。

此时，伐木设计师决定避免这种混乱。记录原始字符串不会产生如此灾难性的后果。