注册
登录
SO业务编排
日志记录，面向方面的编程和依赖注入-试图使所有事情变得有意义
返回
日志记录，面向方面的编程和依赖注入-试图使所有事情变得有意义
作者:
只怕再见是故人
发布时间:
2024-04-11 08:39:50 (14天前)
<p>我知道日志记录是AOP的主要用例。另外，日志记录包装器还作为您要使用DI的情况的示例，以便类不与特定的日志记录实现耦合。但是，有些人认为记录包装器是反模式。首先，这种观点是因为在大多数情况下，包装器趋于简单化，并且删除了日志记录框架特有的许多功能。如果实现这些特定功能，为什么不直接使用框架。</p><p>我知道Common.Logging门面尝试为您抽象出log4Net，EntLib和NLog的大量功能。但是，即使在这里，我们仍然对Common.Logging有所依赖。不是以关于接口等的代码/单元测试方式进行的，而是如果项目终止（自上一发行版以来已经一年多了），或者您希望稍后切换到不受支持的记录器，则可能会导致问题。</p><p>也就是说，如果通过AOP实现日志记录，是否甚至有必要使用DI作为日志记录依赖项（即，为什么不直接引用NLog）呢？是的，代码的AOP部分将紧密耦合，但是要进行单元测试的类的逻辑却没有日志依赖（至少在编织发生之前）。在这一点上，我有点迷茫（我还没有尝试过AOP）。编织后，未将DI用于AOP代码是否会对单元测试被测方法造成问题？还是可以在不编写AOP代码的情况下进行一次单元测试？</p><p>除非软件用户需要日志记录，否则我不确定测试使用模拟进行日志记录有多大用处。我认为被测试方法的业务逻辑是大多数测试人员所感兴趣的。最后，如果要使用TDD / BDD，就不必使用DI来记录AOP代码中的日志依赖吗？还是只是不试驾 AOP？</p><p>如您所见，我正在尝试了解最实际的方法是开发一种应用程序，该应用程序既要使用AOP来解决交叉问题，又要使用DI来进行设计/测试。由于AOP相对较新，并且日志记录是最常见的示例，因此推荐的方法是什么？</p>
收藏
举报
2 条回复
1#
回复此人
春风助手
|
2020-08-11 11-46
日志记录不是服务，而是一个跨领域的问题。因此，最好用Decorator实现。但是，添加大量Decorators只是为了启用各种不同服务的日志记录会违反DRY，在这种情况下，您可以将这些Decorators进一步发展为单个Interceptor。 尽管可以使用IL编织实现AOP，但更好的选择是使用支持动态拦截的DI容器，因为它是一种轻量级的解决方案。 这使您能够将具体服务与日志完全脱钩。那么在那种情况下，我会说没有理由包装任何特定的日志记录框架，因为如果您想更改日志记录框架，则只需更改单个Interceptor。 这是一个讨论用于装饰的装饰器和拦截器的示例（非常类似于记录）。http://blog.ploeh.dk/2010/09/20/InstrumentationWithDecoratorsAndInterceptors.aspx http://blog.ploeh.dk/2010/09/20/InstrumentationWithDecoratorsAndInterceptors.aspx 如果您想了解有关AOP和DI的更多信息，可以在线查看我在2010年哥本哈根GOTO上的演讲。http://channel9.msdn.com/Events/GOTO/GOTO-2011-Copenhagen/CPH-Aspect-Oriented-Programming-with-Dependency-Injection
编辑
登录
后才能参与评论
