包装 log4net 以减少耦合是反模式吗?
包装 log4net 以减少耦合是反模式吗?或者将记录器实例注入公共属性(反模式)?您如何处理 log4net 依赖项?
Is wrapping log4net to reduce coupling an antipattern? Or injecting the logger instance into a public property an antipattern? How do you approach the log4net dependency?
如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱,如果其他用户或者作者回复了您的评论,将不能在第一时间通知您!
发布评论
评论(3)
出于以下原因包装记录器 -
所以,我的观点是很好地包装它。
Wrap a logger for below reasons -
So, my view is good to wrap it.
服务定位器是考虑 .NET 社区前沿的许多人都反对这种反模式。我想说,日志记录通常是我们应用程序的一个非常良性的功能。它本质上是“只写”的。我们永远不会根据日志系统的查询做出决策。
log4net也是一个很容易关闭的系统,不会抛出异常,默默地失败,可以动态更新其配置......一旦进入,几乎没有理由交换实现。
所以,我说,在应用程序中代码,直接使用就可以了。
The service locator is considered an anti-pattern by many on the leading edge of the .NET community. I would say that logging is usually a very benign feature of our applications. It's essentially "write-only". We are never making decisions based on queries of the logging system.
log4net is also a system that's easy to turn off, doesn't throw exceptions, silently fails, can update its configuration on the fly... there's almost no reason to swap out implementations once its in.
So, I say that, in application code, it's ok to use it directly.
我们定义了一个日志记录接口,并有一个 log4net 实现、一个 unitTest 实现和一个 null 实现。
我们使用依赖注入来传递loggingInterface实现。
单元测试实现具有附加方法,例如“bool ErrorWasLogged()”,以便在我们的单元测试中我们可以断言已记录重要信息。对于我们对测试记录内容不感兴趣的测试,我们使用 null 实现。
We define a logging interface, and have a log4net implementation, a unitTest implementation and a null implementation.
We use dependency injection to pass a loggingInterface implementation around.
The unit test implementation has additional methods, like 'bool ErrorWasLogged()', so that in our unit tests we can assert that important information is logged. For tests where we are not interested in testing what was logged, we use the null implementation.