设计模式 – 日志记录和配置系统：循环依赖

假设在启动时从配置文件加载应用程序的初始设置的典型方案.该应用程序还有一个记录器.记录器的参数(例如,详细程度,日志文件路径等)理想地也存储在配置文件中.然而,例如,还希望配置加载器记录关于参数加载的信息

Attempting to load parameter LogVerbosity. Parameter is absent. Using the default value: 4.

因此,我们看到两个组件之间存在循环依赖关系.配置加载程序需要一个即用型记录器,记录器需要配置参数来初始化自身.在我看来这是一个典型的问题,足以让它有规范的解决方案,但我无法找到任何东西.

当然,人们可以推出一些临时解决方案,但我对最佳行业实践感兴趣.

希望这个问题有道理.

我会说规范的解决方案是：不要混合日志和配置！

想象一下,配置文件解析会触发一个错误(但你还不知道！).您更改配置文件以启用日志记录.现在解析不会触发错误,一切看起来都正确,直到你再次禁用日志记录…

因此：更一般地说,原则上,人们希望最大限度地减少调试基础设施(包括日志记录)引入程序的中断;在理想情况下,调试功能将与应用程序执行的任何操作正交,以避免导致heisenbugs.将正常配置与日志记录配置混合已经违反此原则.

但是根据经验,您可以看到众所周知的日志库如何工作：它们都有自己的配置文件,与应用程序中的任何配置无关,因此您可以更改日志记录行为,而无需弄乱应用程序本身.所以你可以重复一个有问题的应用程序运行,只改变它的日志记录行为,希望没有别的.这就是Log4j及其系列端口或已经提到的nlog的工作方式.