Spring AOP 是用纯 Java 实现的。不需要特殊的编译过程。Spring AOP 不需要控制类加载器的层次结构,因此适合在 Servlet 容器或应用服务器中使用。
Spring AOP 目前只支持 方法执行连接点(建议在 Spring Bean 上执行方法)。字段拦截没有实现,尽管可以在不破坏 Spring AOP 核心 API 的情况下增加对字段拦截的支持。如果你需要增强字段访问和更新连接点,可以考虑使用 AspectJ 这样的语言。
Spring AOP 的 AOP 方法与其他大多数 AOP 框架不同。其目的不是提供最完整的 AOP 实现(尽管 Spring AOP 的能力很强)。相反,其目的是在 AOP 实现和 Spring IoC 之间提供一个紧密的整合,以帮助解决企业应用中的常见问题。
因此,例如,Spring 框架的 AOP 功能通常是与 Spring IoC 容器一起使用的。切面是通过使用正常的 Bean 定义语法来配置的(尽管这允许强大的 「自动代理 (auto-proxying)」功能)。这是与其他 AOP 实现的一个重要区别。你不能用 Spring AOP 轻松或有效地做一些事情,比如增强非常细粒度的对象(通常是领域对象)。在这种情况下,AspectJ 是最好的选择。然而,我们的经验是,Spring AOP 为企业级 Java 应用中的大多数问题提供了一个很好的解决方案,这些问题是可以用 AOP 来解决的。
Spring AOP 从未努力与 AspectJ 竞争,以提供一个全面的 AOP 解决方案。我们认为,Spring AOP 等基于代理的框架和 AspectJ 等完整的框架都很有价值,它们是互补的,而不是竞争的。Spring 将 Spring AOP 和 IoC 与 AspectJ 无缝集成,以便在基于 Spring 的应用架构中实现 AOP 的所有用途。这种整合并不影响 Spring AOP API 或 AOP 联盟的 API。Spring AOP 仍然是向后兼容的。关于 Spring AOP API 的讨论,请参见下一章。
:::info Spring 框架的核心原则之一就是非侵入性。这就是不应该强迫你在业务或领域模型中引入框架特定的类和接口的想法。然而,在某些地方,Spring 框架确实让你选择将 Spring 框架特定的依赖关系引入你的代码库。给你这样的选项的理由是,在某些情况下,用这样的方式来阅读或编码一些特定的功能可能会更容易。然而,Spring 框架(几乎)总是为你提供选择:你可以自由地做出明智的决定,哪种选择最适合你的特定用例或场景。
与本章相关的一个选择是,选择哪种 AOP 框架(以及哪种 AOP 风格)。你可以选择 AspectJ、Spring AOP 或两者。你还可以选择@AspectJ 注解式方法或 Spring XML 配置式方法。本章选择首先介绍 @AspectJ 风格的方法,这不应该被认为是 Spring 团队倾向于 @AspectJ 注解风格的方法,而不是 Spring XML 配置风格。
参见《选择使用哪种 AOP 声明风格》,以获得对每种风格的 「原因和理由 」的更完整讨论。 :::