.net - 日志记录、面向方面的编程和依赖注入(inject) - 试图理解这一切

Question

我知道日志记录是 AOP 的主要用例。此外，日志包装器也被举例说明当您想要使用 DI 以便类不与特定的日志记录实现耦合时。但是，some consider logging wrappers an anti-pattern .首先，这种观点是因为在大多数情况下，包装器趋于简单化，并删除了日志框架的许多特定功能。如果您实现了这些特定功能，为什么不直接使用框架。

我知道 Common.Logging尝试为您抽象 log4Net、EntLib、NLog 的大量特性的外观。然而，即使在这里，我们仍然对 Common.Logging 有某种依赖。不是以关于接口(interface)等的代码/单元测试方式，但如果项目终止(自上次发布以来已经过去一年多)，或者您想稍后切换到不支持的记录器，这可能会导致问题。

也就是说，如果日志是通过 AOP 实现的，是否甚至需要使用 DI 来实现日志依赖 (即为什么不直接引用说NLog)？是的，代码的 AOP 部分将紧密耦合，但是想要进行单元测试的类的逻辑没有日志记录依赖关系(至少在编织发生之前)。正是在这一点上，我有点迷茫(我还没有尝试过 AOP)。编织之后，如果没有对 AOP 代码使用 DI，会不会导致对被测方法进行单元测试时出现问题？或者可以在不编织 AOP 代码的情况下进行单元测试吗？

除非日志记录是软件用户的要求，否则我不确定使用模拟测试日志记录是否有用。我认为被测方法的业务逻辑是最感兴趣的测试。最后，如果想使用 TDD/BDD，难道不是必须使用 DI 来实现 AOP 代码中的日志依赖吗？还是只是不试驾 AOP 方面的东西？

正如您所看到的，我试图了解最实用的方法是开发一个将 AOP 用于横切关注点和 DI 用于设计/测试的应用程序。 由于 AOP 相对较新，而日志记录是最常见的示例，那么推荐的方法是什么？

Answer 1

日志记录不是一项服务，它是一个 cross-cutting concern .因此，最好使用 Decorator 来实现。 .但是，添加大量装饰器只是为了启用各种不同服务的日志记录往往会违反 DRY ，在这种情况下，您可以进一步将这些装饰器演变为单个拦截器。

虽然您可以使用 IL weaving 来实现 AOP，但更好的选择是使用支持动态拦截的 DI Container，因为它是一种更轻量级的解决方案。

这使您能够将具体服务与日志记录完全分离。在这种情况下，我会说没有理由包装任何特定的日志框架，因为如果您想更改日志框架，您可以只更改单个拦截器。

Here's an example谈论用于检测的装饰器和拦截器(非常类似于日志记录)。

如果想了解更多关于AOP和DI的知识，可以view online this talk I gave at GOTO Copenhagen 2010 .