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配置风格的暗示。
