在春季项目中AOP最常见的用途是什么？

Question

在审查了AOP模式之后，我对我在春季项目中如何使用它以及如何使用它的方式感到不知所措。

我想将它用作所有财务业务逻辑的审计日志系统。它似乎很容易整合。但是我想听听你对此的看法。

问题是 - 对于这种模式，我应该考虑哪些其他用途？我不介意重构我目前使用AOP的逻辑，只要它有好处。

Answer 1

最常见的用法是您的应用程序具有交叉问题，即将要在多个类/层中编写的一段逻辑或代码。

这可能会根据您的需求而有所不同。一些非常常见的例子可能是：

1. 交易管理
2. 登录
3. 异常处理（特别是当您可能希望有详细的跟踪或有一些从异常中恢复的计划时）
4. 安全方面
5. 仪表

希望有所帮助。

Answer 2

最常见的用法可能是使用@Transactional进行声明式事务处理。

Answer 3

除了Axel提到的日志记录/审计和声明式事务处理之外，我想说AOP的另一种用法是作为请求拦截器。例如，假设您需要截取服务器的所有请求，以便您可以使用它执行某些操作（可能是为了跟踪哪个应用程序正在向其他应用程序或什么数据库发送什么请求等）。

Answer 4

您可以使用AOP来解决安全问题，例如允许/禁止方法访问。 aop的另一个用途是测试你的应用程序性能。

Answer 5

使用AOP进行审计日志记录是对AOP的完美有效使用。您可以关闭它进行测试，并根据生产中的需求变化进行更改。

在这种情况下唯一的缺点是，如果您计划通过SQL执行审核日志。将这种审计作为触发器直接在DB中实现可能更有效。

Answer 6

作为一个与@Axel所说的略有不同的答案，使用它来自动拦截所有数据访问调用并适当地应用事务是惊人的。我已经设置了实现对我的dao包的所有调用，这些调用在事务中不以“get”开头，然后在以“get”开头的方法中执行的任何操作都被视为只读。这很棒，因为除了初始设置之外，我不必担心它，只需遵循命名惯例。

Answer 7

它可以用于使用客户端库（如dropwizard，prometheus）公开自定义指标（服务仪表）以进行服务警报和监视。

它帮助了我们

1. 将此检测代码（不是业务逻辑）保留在实际业务逻辑之外

2. 将这些跨领域关注点放在一个地方。

3. 以声明方式在需要的地方应用它们。

例如， 公开

1. REST AIP返回的总字节数-（可以在咨询后完成）
2. REST API花费的总时间，即服务器输入和服务器输出边缘（可以使用周围建议完成）。