Spring AOP 是用纯JAVA 实现的. 不需借助JAVA代码在编译处理阶段来实现. Spring 是在运行期实现的。
AOP的实现可以在编译,加载,运行三个阶段来实现；
Spring AOP 也不需要控制类的装置机制来实现. 它和适合用在servlet 容器和应用程序服务中。
Spring AOP 当前仅仅支持方法执行连接点（只对Spring beans 方法的执行进行通知）.
字段拦截没有被Spring 实现，尽管可以实现对字段的访问进行拦截而不需要破坏核心的Spring AOP 接口。
如果你需要字段访问和更新类型的通知那么你可以考虑使用AspectJ 。
Spring AOP 和其他大多数AOP 框架比起来还是有所不同的，Spring AOP 的目标不是去提供一个最完整的AOP实现（尽管Spring AOP 非常的牛）
而是去实现AOP 和Spring IoC 的紧密整合，去帮助企业解决公共的问题。
（言外之意 虽然Spring AOP 不是特别的完善 但是如果你真有需要他已经整合了功能更完善的AOP 框架供你选择）
Spring 框架的AOP通常是和Spring Ioc 容器相结合来使用的.
切面是通过使用正常的Bean 定义符来配置的 (虽然允许使用强大的 自动代理能力).
这是和其他AOP实现比起来最明显的不同之处。
在某些情况下你使用Spring AOP 会非常的复杂和低效（典型的领域对象不在Spring 容器中）
AspectJ 是一个更好的选择在这种情况下
我们的经验是Spring AOP 为企业JAVA 应用程序中的大多数问题提供一个漂亮的解决方案。
Spring AOP 从来都没想和AspectJ去竞争去比谁能为用户提供更完善的AOP方案。
我们相信这两个基于代理来实现AOP的框架（Spring AOP 和成熟的AspectJ）都有自身的价值并且他们是互补的。
Spring无缝的把Aspectj 和spring 的AOP ，容器进行了整合。
为所有AOP的用户提供一致性的应用程序架构(基于Spring 框架)，这种整合不影响Spring AOP 的API 和AOP 联盟API.
Spring AOP 是向后兼容的 。
Spring 框架的核心理念是非侵入，
这就是说Spring不会强制性的把和你业务逻辑,领域模型无关的Spring相关的类和接口引入到你的代码中。
在某些地方,Spring框架会给你一个选择是否要引入Spring框架依赖到你的代码库中；
给你选择的依据是因为在某些场景中你只是为了简单的实现一些功能。
不管如何Spring 总是会给你这样子的选择，让你可以做出一个明智的决定，那种方案给适合你当前的使用场景。
比如选择哪种AOP框架，或AOP风格；那么你可以选择AspectJ 或者 Spring AOP ，两个都选Spring 也支持。
你可以选择@Aspectj 这种基于注解风格的或者是基于XML配置的方式；