日志记录，面向方面的编程和依赖注入-试图使所有事情变得有意义

Question

我知道日志记录是AOP的主要用例。另外，日志记录包装器还作为您要使用DI的情况的示例，以便类不与特定的日志记录实现耦合。但是，有些人认为记录包装器是反模式。首先，这种观点是因为在大多数情况下，包装器趋于简单化并删除了日志记录框架特有的许多功能。如果要实现这些特定功能，为什么不直接使用框架。

我知道Common.Logging门面尝试为您抽象出log4Net，EntLib和NLog的大量功能。但是，即使在这里，我们仍然对Common.Logging有所依赖。不是以关于接口等的代码/单元测试方式进行的，而是如果项目终止（自上一个发行版以来已经一年多了），或者您希望稍后切换到不受支持的记录器，则可能会导致问题。

也就是说，如果通过AOP实现日志记录，是否甚至有必要使用DI作为日志记录依赖项（即，为什么不直接引用NLog）呢？是的，代码的AOP部分将紧密耦合，但是一个人要进行单元测试的类的逻辑没有日志依赖（至少在编织发生之前）。在这一点上，我有点迷茫（我还没有尝试过AOP）。编织后，未将DI用于AOP代码是否会对单元测试被测方法造成问题？还是可以在不编写AOP代码的情况下进行一次单元测试？

除非软件用户需要日志记录，否则我不确定测试使用模拟进行日志记录有多大用处。我认为被测方法的业务逻辑是大多数测试所感兴趣的。最后，如果要使用TDD / BDD，是否就不必使用DI来记录AOP代码中的日志依赖项？还是只是不试驾 AOP呢？

如您所见，我正在尝试了解最实际的方法是开发一种应用程序，该应用程序将同时使用AOP来解决交叉问题，并使用DI来进行设计/测试。由于AOP相对较新，并且日志记录是最常见的示例，因此推荐的方法是什么？

Answer 1

日志记录不是服务，而是一个跨领域的问题。因此，最好用Decorator实现。但是，添加大量Decorators只是为了启用各种不同服务的日志记录会违反DRY，在这种情况下，您可以将这些Decorators进一步发展为单个Interceptor。尽管可以使用IL编织实现AOP，但更好的选择是使用支持动态拦截的DI容器，因为它是一种轻量级的解决方案。这使您能够将具体服务与日志完全脱钩。那么，在这种情况下，我会说没有理由包装任何特定的日志记录框架，因为如果您想更改日志记录框架，则只需更改单个Interceptor。这是一个讨论用于装饰的装饰器和拦截器的示例（非常类似于记录）。

Answer 2

动态拦截也是 AOP ：）但是，我将您的问题解释为与IL编织有关的AOP有关。在那种情况下，对于一个未开发的项目，我绝对看不到它有任何好处，但是在遗留代码上，它可能是可行的，因为它允许您将方面应用于静态，内部和/或私有类型和成员，而动态拦截则要求您针对接口（或基类）进行编程。