【发布时间】：2017-07-17 07:46:25
【问题描述】：
由于有这么多日志框架，我希望为每个应用程序编写一个抽象，以便我控制可以插入哪个日志框架。这意味着我在例如 Log4Net 或 NLog 上不可靠，但我提供了一个接口/抽象，然后在我自己的抽象中提供了插件框架。
沿着这些思路（可能有点简化），我可以将其传递给任何需要依赖项的对象。
interface ILogger {
void LogMessage(string message, Severity severity);
void LogDebug(string message);
void LogInfo(string message);
void LogWarning(string message);
void LogError(string message);
void LogFatal(string message);
}
之后我的计划是为我想使用的日志框架编写适配器/实现 - 这样我就可以在必要时插入任何其他日志框架。
public sealed class Log4NetLogger : ILogger {
/// Implementation and Log4Net specifics here
}
public sealed class NlogLogger : ILogger {
/// Implementation and Log4Net specifics here
}
这些我将通过 IoC 或资源定位器注入/实例化，具体取决于我正在处理的应用程序的实现细节。
问题：我不知道是否是一个好主意？从头开始写这篇文章，考虑一下
- 日志框架内的上下文信息丢失
- 重新发明轮子
- 性能下降
另一方面，好处对我来说是：
- 如果操作正确，我可以切换出去，或者添加一个非常自定义的实现。
- 之后我不需要再接触已经存在并投入生产的类的内部结构，从而遵守可靠的原则，尤其是开放/封闭原则 - 引入更少的错误。
任何指导、备注、警告应该做和不应该做的 - 或者对现有抽象的引用可能很方便，非常受欢迎！
谢谢， 伊夫
【问题讨论】：
-
LibLog 非常值得一试。
-
非常感谢您的提示！到现在才碰到Common.Logging，这个好像轻了一点！
-
您总是可以要求一个类型作为泛型参数（代替您接口的实际参数），或者如果泛型参数给您带来问题，您只需为其定义一个抽象类；如果框架的差异是一个问题。然后，您将提供一个通用的
LogParameters抽象类型，其中包含大多数框架的可能通用参数，无论哪种情况。一个隐式，一个显式（如指南抽象类）。 -
@welrocken 你的意思是像
LogDebug<TClass>()这样我可以抓住它的来源。也许还添加CallingMemberName 属性+参数？这确实是个好主意。