集中应用程序日志的优缺点是什么？

我希望了解使用 AOP（例如使用 AspectJ）将所有应用程序日志集中到单独文件中的利弊。

Logging is know for being a cross-cutting concern。但是，我从未遇到过将所有日志集中到单个或一堆文件中的人。因此，我想知道为什么。

这样做的利弊是什么？

我希望了解集中所有的利弊应用程序使用 AOP（例如使用 AspectJ）登录到单独的文件中。

我将交替使用术语 AOP 和 AspectJ。尽管如此，AOP 是范式，AspectJ 实现了它，就像 OOP 和 Java 一样。

使用 AOP 将横切关注点 (CCC) 集中到它们自己的模块（例如方面）的好处与使用 OOP 的模块化关注点的好处相似。这些好处在论文和书籍的文献中有所描述，例如：

和许多其他人。可以将其中一些好处总结如下：

减少代码重复；一个功能（例如，日志）不是在几个不同的地方重复，而是在一个方面拥有它。然后可以使用切入点的概念将该功能应用于这几个地方；
降低领域相关和横切相关关注点之间的耦合（即关注点分离）；例如，从域代码中删除日志记录遵循 single-responsibility principle;
代码重用性的增强；由于前面提到的关注点分离，一个（例如）增加了封装基础代码的模块和封装日志的模块的重用性；
处理代码tangling and scattering issues；如下图所示

日志 1 和 2 不是直接与域代码纠缠，而是在单独的模块中重复和分散（即 {{ 1}} 和 Class A)，我们将那些与日志相关的功能封装到一个方面。

文献中有一些关于 AOP 在横切关注点（例如日志记录）模块化方面的好处的论文：

S。 Canditt 和 M. Gunter。现实世界中面向方面的日志记录系统。在第一届 AOSD 方面、组件和模式研讨会上基础设施软件 (AOSD-2002)，2002 年 3 月。

人们可以在文献中读到的 AOP 的缺点是 those typical of a learning/integrating a new technology，即：

论文报道的其他缺点，例如：

可以总结为：

必须学习一种新的范式；
缺乏工具支持；
编织的性能；
使代码更难推理，因为 CCC 相关代码已移至别处。例如，相同的论点可以应用于子类化或装饰模式的使用。但是，在 Class B 的情况下，IDE 通过显示被拦截的连接点来缓解这些问题。另一种解决方案是例如使用注释并拦截这些注释：

@Logging public void some_method(){...}

当程序员查看注解时，立即知道该方法正在被切入点拦截。这种方法的缺点是您kind再次将 CCC 与域代码混合在一起，尽管只是以注释的形式。

另一方面，人们可能会争辩说，由于与领域相关的关注点和 CCC 现在封装在不同的模块中，因此更容易孤立地推理它们。

对基本代码的更改可能导致连接点错误地下降切入点范围内或外。

例如，添加新方法或更改其签名可能会导致切入点拦截它们或停止拦截它们。有一些技术可以缓解此类问题。但是，在我的选择中，解决方案是工具。在 Java 中重命名方法时，人们希望 IDE 能够安全地应用这些更改。

连接点模块的粒度。使用 AspectJ（使用 Spring AOP 甚至更糟）可能难以获得日志记录所需的本地上下文，例如本地变量，这可能会迫使您重构代码，以便您可以公开所需的joinpoints -- known in requirements engineering as scaffolding。另一方面，重构您的代码实际上可能会改进它。来自："21. Why can't AspectJ pick out local variables (or array elements or ...)?" 可以阅读：

用户有时希望 AspectJ 挑选出更多的连接点，包括方法局部字段访问、数组元素访问、循环迭代、方法参数求值

大多数结果都没有意义，对于各种原因：对于Java程序员来说，它不是一个普遍理解的单元

我们更愿意在连接点模型中非常保守语言，所以一个新的连接点必须是有用的、合理的，并且可执行。提出的新连接点中最有希望的是用于异常抛出子句和同步块。

您需要评估在您的上下文中，在您的代码库中添加一个额外的层（即横向模块化）是否值得；并针对替代方法（例如代码生成器、框架或设计模式）进行评估。

在日志记录的情况下，上述一些问题没有问题，因为如果出现问题......好吧，您只是丢失或添加一些日志记录。

意见基础部分

日志记录是一个跨领域的问题。但是，我从未遇到过将所有日志集中到单个或一堆文件中的人。因此，我想知道为什么。

关注点分离是一种不好的做法吗？！（除非你把它带到极端不）。我肯定会说这不是一个坏习惯，值得吗？！嗯，这更复杂，取决于上下文。

我个人讨厌看到混合了日志功能的漂亮代码片段。 IMO 考虑到软件必须处理许多其他变量，而不仅仅是每个 si 的代码，例如紧迫的期限、不将日志记录与基本代码混合似乎没有更高的优先级。