Spring AOP 的能力与目标
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 Framework 的 AOP 功能通常与 Spring IoC 容器结合使用。切面使用普通的 bean 定义语法进行配置(尽管这提供了强大的“自动代理”功能)。这是与其他 AOP 实现的关键区别。使用 Spring AOP 无法轻松高效地完成某些事情,例如通知非常细粒度的对象(通常是领域对象)。在这种情况下,AspectJ 是最佳选择。然而,我们的经验表明,对于企业 Java 应用中适合使用 AOP 的大多数问题,Spring AOP 提供了出色的解决方案。
Spring AOP 从不试图与 AspectJ 竞争以提供全面的 AOP 解决方案。我们认为,基于代理的框架(如 Spring AOP)和功能完善的框架(如 AspectJ)都很有价值,它们是互补而非竞争关系。Spring 无缝地将 Spring AOP 和 IoC 与 AspectJ 集成,以便在一致的基于 Spring 的应用架构中实现 AOP 的所有用途。这种集成不影响 Spring AOP API 或 AOP Alliance API。Spring AOP 保持向后兼容。关于 Spring AOP API 的讨论,请参见 下一章。
Spring Framework 的核心原则之一是非侵入性。这意味着您不应被迫将特定于框架的类和接口引入到您的业务或领域模型中。然而,在某些地方,Spring Framework 确实提供了将特定于 Spring Framework 的依赖项引入代码库的选项。提供这些选项的理由是,在某些场景下,以这种方式阅读或编写某些特定功能可能更容易。然而,Spring Framework(几乎)总是为您提供选择:您可以自由地做出明智的决定,选择最适合您的特定用例或场景的选项。 与本章相关的一个选择是选择哪种 AOP 框架(以及哪种 AOP 风格)。您可以选择 AspectJ、Spring AOP 或两者。您还可以选择 @AspectJ 注解风格方法或 Spring XML 配置风格方法。本章选择首先介绍 @AspectJ 风格方法,这不应被视为 Spring 团队偏爱 @AspectJ 注解风格方法而非 Spring XML 配置风格方法的迹象。 有关每种风格的优缺点的更完整讨论,请参阅 选择使用哪种 AOP 声明风格。 |