Castle Windsor 的伐木设施有哪些用例？

Question

我最近一直在学习通过依赖注入和使用 Castle Windsor 来实现控制反转。我喜欢。我得到它。我头上的灯泡亮着。但是我对日志记录工具和ILogger 接口有一个唠叨的担忧。那真的在那里做什么？是给我的，还是只给温莎本身？

由于ILogger 旨在抽象出 log4net 和 Nlog 以及它支持的任何其他日志框架之间的差异，它必须代表它们之间的最小公分母。各种框架相似，但不一定相同。如果其中一个有一些很棒的功能，而另一个没有，则要么必须将其排除在 ILogger 之外，要么其他日志记录框架的 ILogger 实现必须对其进行无操作实现，或者其他不太令人满意的东西。

早在 Windsor 之前，我就是 log4net 的粉丝，我喜欢的很多库都使用它，比如 NHibernate。因此，如果我正在构建一个新应用程序，我将使用 log4net。我愿意承诺，并且我认为它是一个稳定的依赖项——例如，与需要System.Web 一样稳定的依赖项。我不会写我的组件来使用ILogger，我会写它们来使用ILog。但我得到的印象是，Windsor 希望我使用ILogger 进行自己的日志记录。当我不应该依赖于我的 IoC 容器时，这难道不是让我的项目依赖于 Windsor 吗？

我看到 Windsor 拥有日志工具的意义，因此它可以使用项目想要使用的任何日志框架来记录自己的操作。这似乎完全合情合理。但是如果我自己的代码不用ILogger，直接去log4net的ILog，那我放弃什么呢？我会后悔吗？

明显的反应是我可能想在六个月内更改日志记录框架。但我不会。 log4net 成熟稳定。这是一个范围有限且定义非常明确的项目，它几乎可以完美地实施。它可以被认为是“完成”。最多，我可能需要编写一个自定义附加程序来处理消息。 （也许出于某种原因，我想将它们写在明信片上并将它们放入邮件中。）但这在 log4net 框架中很容易完成，我会像使用任何其他 log4net appender 一样使用它。与更改 Web 平台相比，我不太可能更改日志记录框架。

Answer 1

您似乎已经下定决心直接使用 log4net。这是完全合理的，因为您认为它是一个稳定的依赖项。我刚刚为我们的项目从 log4net 切换到 NLog，所以将来您可能会更改日志框架，这就是抽象的优势所在。

在考虑使用日志抽象时的另一个考虑因素（除了丢失特定于特定日志框架的功能）是学习抽象的额外开销。这会使开发人员更容易掌握代码的复杂程度吗？

在我们的案例中，我们发现 NLog 非常容易直接安装和配置，因此我们决定放弃自定义日志记录抽象并从 log4net 切换（我们发现它的 xml 配置与 NLog 相比有点冗长）。