Spring AOP capabilities and goals

Spring AOP是用纯的java实现的。不须要任何个性的实现过程。Spring AOP不须要控制类加载器，而且它适用于Servlet容器或者应用服务器。

Spring AOP当前只支持方法执行的链接点（通知Spring beans的方法执行）。字段的拦截没有实现，虽然支持字段的拦截，能够在不破坏核心Spring AOP API的状况下添加。若是你须要通知字段获取和根性链接点，能够考虑一种相似AspectJ的语言。

用Spring AOP的方式实现AOP不一样于大多数其余的AOP框架。它的目标不是提供一种最完整的AOP实现（虽然Spring AOP已经很是的强大）；它更倾向于在AOP实现和Spring IoC之间提供一种封闭的整合，从而帮补解决企业应用中的哪些通用的问题。

例如，Spring框架的AOP功能一般与Spring Ioc容器结合使用。Aspects使用通用的bean 定义的语法来配置（虽然它容许强大的自动代理的方式）：与其余的AOP实现相比，这是一个很重要的不一样点。有些事情若是你不使用Spring AOP，将很难或者不能高效的去作，例如通知细粒度的对象（如典型的业务对象）：而在这种状况下AspectJ是最好的选择。然而，咱们的经验是，Spring AOP为企业级Java应用中大多数问题提供了一个优秀的解决方案，这些问题在AOP中很容易控制。

Spring AOP历来没有为与AspectJ竞争提供一个综合的AOP而纠结。咱们相信这样两种基于代理的框架如Spring AOP和成熟的AspectJ都是有存在价值的，而且他们是相互补充的，而不是相互竞争的关系。Spring 2.0将Spring AOP和IoC与AspectJ无缝整合，从而是AOP的所有使用在一系列的基于Spring的应用框架中适应能力更强。这个整合没有影响到Spring AOP的API或者AOP Alliance API:Spring AOP保持着向后兼容。

Spring框架的一个核心原则就是非侵入性；这就是说你不会被强制引入框架的个性类和接口到你本身的业务领域模型。然而在Spring框架的一些地方给了你引入Spring框架特性的依赖到你的代码中：给你这些东西的缘由是，在一些特定的场景，以这种方式编码可能更加的可读性.Spring框架大多数状况下给你一些选择，这样你就能够自由的作一个合理的决定，用来适应一些特定的状况和场景。

你须要选择使用AspectJ仍是Spring AOP或者两者都用，并且你也要选择使用@AspectJ注解方式或者Spring Xml配置风格的方式。事实上本章节选择使用@AspectJ注解，首先要避免被认为是一种@AspectJ注解优于Spring Xml配置风格的暗示。