包装日志框架答案

【问题标题】：Wrapping Logging Frameworks包装日志框架
【发布时间】：2015-03-11 01:29:24
【问题描述】：

在寻找日志框架（log4net、NLog 等）时，我发现它们中的大多数都符合一个非常基本的接口。 Common.Logging 接口是创建抽象和单一合约的好方法，通过使用适配器等，在日志框架和您的代码之间。 Common.Logging提供如下接口（总结）：

void Trace(object message);  
void Debug(object message);  
void Info(object message);  
void Warn(object message);  
void Error(object message);  
void Fatal(object message);

对于应用程序日志记录，我们是否不想要更具表现力和明确性的东西？

例如，我可能想要记录更多字段。也许我想要一个“方法”或“上下文”字段？也许我真的不喜欢这些方法的命名约定。它们不是动词；违反我们标准的东西。这也可能提供了太多的灵活性 - 谁知道每个开发人员将如何处理日志记录。

出于这个原因，我很想用更明确的东西来包装Common.Logging：

void LogTrace(string context, string message, string parameters);
void LogDebug(string context, string message, string parameters);
void LogInfo(string context, string message, string parameters);
void LogWarning(string context, string message, string parameters);
void LogError(string context, string message, string parameters);
void LogError(string context, string message, string parameters, Exception ex);
void LogFatal(string context, string message, string parameters);
void LogFatal(string context, string message, string parameters, Exception ex);

这是否可取，这种方法有什么缺点吗？

【问题讨论】：

我没有看到优势。您不是在抽象您指定的内容。带有对象消息的方法尽可能地抽象。当然，您可以将您的 API 放在上面以获得类型安全的 API。你知道你的消息会被序列化成一个字符串，那为什么还要有显式的参数呢？使用匿名类型或“LogMessageType”。为日志构建一个新的 API，但它是特定于应用程序的，而不是“抽象的”。看看：github.com/damianh/LibLog
@StefanOssendorf：抱歉。更新的问题。我想从本质上进行包装，而不是抽象。

标签： .net logging log4net enterprise-library nlog

【解决方案1】：

通过对不同的日志框架使用包装器，您将只使用日志框架的常用功能。每个日志框架都有其优点和缺点，在大多数情况下，您应该根据日志记录的要求来选择日志框架并查看这些点。

【讨论】：

正确。另一种说法。当您使用抽象版本（Common.Logging）时，您将失去混凝土库（例如 NLog 或 Log4Net）的一些“更精确”的功能。所以你必须选择哪个更重要。我们使用 Common.Logging 并接受了使用特定混凝土（我们世界中的 NLog）的轻微“损失”......

【解决方案2】：

您是否考虑过在 Fody 下使用 Anotar 而不是 Common.Logging？每个方法，Trace、Debug、Fatal 等，都有预期的“消息”、“参数”和“异常”重载。像 Common.Logging 一样，它很容易在日志库之间切换。

【讨论】：