我已经将通用基础设施库与 log4net 一起使用，并且运行良好。 我使用它而不仅仅是 log4net，因为我的客户表示希望保留使用 Microsoft 企业库 (EntLib) 日志记录的可能性。
我不确定为什么 Brad Bruce 建议不要使用这个抽象层 - 使用它是显而易见的，并且不会造成任何问题。 在我看来，log4net 远远领先于其他任何可用的东西，但有些人想要 EntLib 只是因为它带有 Microsoft 标记，增加了舒适度。 通过使用抽象层，我让我的客户可以自由地切换到 EntLib，而无需更改代码或重新编译 - 只需更改配置文件。
I've used the Common Infrastructure Library with log4net, and it worked well. I used it rather than just log4net because my client expressed the wish to keep open a possibility to use Microsoft's Enterprise Library (EntLib) logging.
I'm not sure why Brad Bruce advises against using this abstraction layer - it was a no-brainer to use and didn't cause any problems. IMO log4net is streets ahead of anything else available, but some people want EntLib just because it has the added comfort factor of the Microsoft stamp on it. By my using the abstraction layer, I give my client the freedom to switch to EntLib without code changes or recompiling - just a configuration file change.
Are you going to be switching between the logging projects mentioned?
Are you distributing source to someone who might be using one of the listed logging projects, that you aren't using?
There are MANY more logging projects than the ones supported by Common.Logging
This appears to be a lot like ODBC did years ago. It's sold as being interchangeable, but as soon as you use one provider specific feature, you can no longer switch.
When something goes wrong in logging you now have 2 layers to debug.
Again; if you're not going to be switching libraries, I wouldn't use the Common.Logging class.
As a quick follow up... I was on a logging kick today, and decided to try to get Chainsaw working so I could have a view of my app's logs in real-time. However, I wasn't able to get a UdpReceiver working in Chainsaw.
The solution was to forget about Chainsaw and enable NLog (via the Common.Logging config settings) and use the NLogViewer instead. NLog and NLogViewer worked together as advertised and I can now view logs as they happen. I was able to incorporate NLog into my app without modifying my code base one bit. The payoff of including the Common.Logging abstraction came much sooner than I ever would have expected.
As I began to utilize log4net in my MVC app I became concerned about the tight coupling of my controller classes with the concrete log4net implementation. It's true that committing to the specific interface defined in Common.Logging (which incidentally mirrors that of log4net) is just that; a commitment. But the 2.0 release of Common.Logging gave me an immediate level of abstraction, and the log4net interface it mimics is battle tested and simple to use. Also, I like the idea of being able to use, test, and experiment with different concrete logging implementations by simply adding a reference and updating a Web.config file.
All of Bruce's points are perfectly valid. The abstraction may be nothing more than a false sense of security and the decision may end up biting me in the butt. Nonetheless, sometimes you just have to err on the side of best practices until bester practices come along. :-)
发布评论
评论（4）
我已经将通用基础设施库与 log4net 一起使用，并且运行良好。 我使用它而不仅仅是 log4net，因为我的客户表示希望保留使用 Microsoft 企业库 (EntLib) 日志记录的可能性。
我不确定为什么 Brad Bruce 建议不要使用这个抽象层 - 使用它是显而易见的，并且不会造成任何问题。 在我看来，log4net 远远领先于其他任何可用的东西，但有些人想要 EntLib 只是因为它带有 Microsoft 标记，增加了舒适度。 通过使用抽象层，我让我的客户可以自由地切换到 EntLib，而无需更改代码或重新编译 - 只需更改配置文件。
I've used the Common Infrastructure Library with log4net, and it worked well. I used it rather than just log4net because my client expressed the wish to keep open a possibility to use Microsoft's Enterprise Library (EntLib) logging.
I'm not sure why Brad Bruce advises against using this abstraction layer - it was a no-brainer to use and didn't cause any problems. IMO log4net is streets ahead of anything else available, but some people want EntLib just because it has the added comfort factor of the Microsoft stamp on it. By my using the abstraction layer, I give my client the freedom to switch to EntLib without code changes or recompiling - just a configuration file change.
您要在提到的日志记录项目之间切换吗？
您是否正在将源代码分发给可能正在使用列出的日志记录项目之一（但您并未使用）的人？
再次; 如果您不打算切换库，我不会使用 Common.Logging 类。
Are you going to be switching between the logging projects mentioned?
Are you distributing source to someone who might be using one of the listed logging projects, that you aren't using?
Again; if you're not going to be switching libraries, I wouldn't use the Common.Logging class.
作为快速跟进...我今天正在记录日志，并决定尝试让 Chainsaw 工作，这样我就可以实时查看应用程序的日志。 但是，我无法让 UdpReceiver 在 Chainsaw 中工作。
解决方案是忘记 Chainsaw 并启用 NLog（通过 Common.Logging 配置设置）并使用 NLogViewer。 NLog 和 NLogViewer 正如所宣传的那样协同工作，我现在可以在日志发生时查看日志。 我能够将 NLog 合并到我的应用程序中，而无需修改我的代码库一点点。 包含 Common.Logging 抽象的回报比我预期的要快得多。
As a quick follow up... I was on a logging kick today, and decided to try to get Chainsaw working so I could have a view of my app's logs in real-time. However, I wasn't able to get a UdpReceiver working in Chainsaw.
The solution was to forget about Chainsaw and enable NLog (via the Common.Logging config settings) and use the NLogViewer instead. NLog and NLogViewer worked together as advertised and I can now view logs as they happen. I was able to incorporate NLog into my app without modifying my code base one bit. The payoff of including the Common.Logging abstraction came much sooner than I ever would have expected.
当我开始在我的 MVC 应用程序中使用 log4net 时，我开始担心控制器类与具体 log4net 实现的紧密耦合。 确实，提交到 Common.Logging 中定义的特定接口（它顺便反映了 log4net 的接口）就是这样； 一个承诺。 但是 Common.Logging 的 2.0 版本给了我一个直接的抽象级别，并且它模仿的 log4net 接口经过了实际测试并且易于使用。 另外，我喜欢通过简单地添加引用和更新 Web.config 文件来使用、测试和试验不同的具体日志记录实现的想法。
布鲁斯的所有观点都是完全正确的。 这种抽象可能只不过是一种错误的安全感，而这个决定最终可能会咬我的屁股。 尽管如此，有时您不得不在最佳实践方面犯错误，直到出现最佳实践。 :-)
As I began to utilize log4net in my MVC app I became concerned about the tight coupling of my controller classes with the concrete log4net implementation. It's true that committing to the specific interface defined in Common.Logging (which incidentally mirrors that of log4net) is just that; a commitment. But the 2.0 release of Common.Logging gave me an immediate level of abstraction, and the log4net interface it mimics is battle tested and simple to use. Also, I like the idea of being able to use, test, and experiment with different concrete logging implementations by simply adding a reference and updating a Web.config file.
All of Bruce's points are perfectly valid. The abstraction may be nothing more than a false sense of security and the decision may end up biting me in the butt. Nonetheless, sometimes you just have to err on the side of best practices until bester practices come along. :-)