作者:手机用户2502895231 | 来源:互联网 | 2022-12-05 16:00
我一直在关注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核心.
1> Ben..:
至少有两个原因.
首先,记录前置字符串插值,而微软尚未发明时间机器.字符串插值仅在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,则会减少一次插值操作.
2> Panagiotis K..:
我怀疑这个问题可以改写为:
他们为什么不提供接受FormattableString的重载,以使用字符串插值语法传递消息模板和参数,就像EF Core用于参数化查询一样?
我会说他们做对了。在这一点上,使用FormattableString带来的好处很小,但会造成很多混乱。
我只是发现Serilog的作者解释了为什么即使语义记录库看起来很适合这种情况,这也不是一个好主意
语义记录
可以说这FormattableString
将是对Serilog之类的语义日志记录库的巨大补充。在这种情况下,内插字符串确实会丢失重要信息。
通话
Log.Information("Logged in {UserId}", loggedInUserId);
不仅会基于模板记录字符串,还会保留参数的名称和值,并将其提供给过滤器和目标。取得相同的结果不是很好:
Log.Information($"Logged in {loggedInUserId}");
Serilog的作者不这么认为,并解释说:
好的变量名不一定是好的属性名
孔并不总是具有明显的名称,例如 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中使用字符串插值,从而导致无效查询。FormattableString
EF Core团队增加了超负荷的能力,从而减轻了这种情况,同时更容易意外导致其他问题。
此时,伐木设计师决定避免这种混乱。记录原始字符串不会产生如此灾难性的后果。