我最近一直在考虑在整个应用程序中抽象我的日志记录。另一个资源上更具体的帖子引发了“共同基础设施图书馆”的建议:
http://netcommon.sourceforge.net/
具体来说,是Common.Logging类,它提供了一个通用接口,可以放在许多日志记录之前(例如log4net)。
我有点讨厌在我的项目中引入另一条第三方代码。
有人使用过这个图书馆吗?我很想听听你的经历。
由于
答案 0 :(得分:4)
我已经将公共基础结构库与log4net一起使用,并且运行良好。我使用它而不仅仅是log4net,因为我的客户表示希望继续使用Microsoft的企业库(EntLib)日志记录。
我不确定为什么布拉德布鲁斯建议不要使用这个抽象层 - 使用它并不会造成任何问题。 IMO log4net领先于其他任何可用的东西,但有些人想要EntLib只是因为它有微软标记的附加舒适因素。通过我使用抽象层,我可以让我的客户自由切换到EntLib而无需更改代码或重新编译 - 只需更改配置文件。
答案 1 :(得分:1)
您是否要在提到的日志记录项目之间切换?
您是否正在向可能正在使用其中一个列出的日志记录项目的人分发源代码?
再次;如果你不打算切换库,我就不会使用Common.Logging类。
答案 2 :(得分:1)
快速跟进......我今天正在进行日志记录,并决定尝试让Chainsaw工作,这样我就可以实时查看应用程序的日志。但是,我无法让一个UdpReceiver在Chainsaw工作。
解决方案是忘记Chainsaw并启用NLog(通过Common.Logging配置设置)并使用NLogViewer。 NLog和NLogViewer按照宣传的方式一起工作,现在我可以查看日志。我能够将NLog合并到我的应用程序中,而无需修改我的代码库。包含Common.Logging抽象的收益比我预期的要快得多。
答案 3 :(得分:0)
当我开始在我的MVC应用程序中使用log4net时,我开始关注我的控制器类与具体的log4net实现的紧密耦合。确实,提交到Common.Logging中定义的特定接口(偶然反映了log4net的接口)就是这样;一个承诺。但是Common.Logging的2.0版本给了我一个直接的抽象级别,它模仿的log4net接口经过了战斗测试并且易于使用。此外,我喜欢通过简单地添加引用和更新Web.config文件来使用,测试和试验不同的具体日志记录实现的想法。
布鲁斯的所有观点都非常有效。抽象可能只是一种虚假的安全感,而决定可能最终会让我陷入困境。尽管如此,有时你只需要在最佳实践方面犯错,直到bester实践出现。 : - )