假定你决定直接使用JDBC或Hibernate的事务来避免JTA的开销。一旦你需要与多个数据源打交道，你会不得不找出所有事务管理代码并用JTA事务来替换它们。这难道不具吸引力？这导致包括我在内的大多数J2EE开发者推荐只使用全局JTA事务，并用像Tomcat这样的简单Web 容器来有效管理事务程序。不管怎样，使用Spring事务抽象，你只要重新配置Spring来使用JTA，而不是JDBC或Hibernate的事务策略就可以了。这是一个配置的修改，不是代码变更。因此，Spring让你的应用程序能随意缩放。
AOP
从2003年起在企业关注问题上(例如一般使用EJB来做的事务管理)使用AOP解决方案大家有了很大的兴趣。
Spring的AOP支持的首要目标是为POJO 提供J2EE支持。Spring AOP能够在应用服务器之间移植，所以没有厂商绑定的风险。它可以工作在web 容器或者是EJB容器中，而且已被成功应用于WebLogic、Tomcat、JBoss、Resin、Jetty、Orion和其他很多应用服务器及web 容器上。
Spring AOP支持方法拦截。所支持的关键AOP概念包括：
拦截(Interception)：自定义的行为能插入到任何接口和类的方法调用的前面或后面。这和AspectJ 术语中的“around advice”相近。
引入(Introduction)：一个执行逻辑(advice)会导致一个对象实现额外的接口。这会引起继承混合。
静态和动态切入点：在程序执行过程中指定发生拦截的地方。静态切入点关注方法签名；动态关注点还能考虑被计算处的方法参数。切入点与拦截器分开定义，这使得一个标准拦截器可以被用在不同应用程序和代码上下文中。
Spring支持有状态的(每个执行逻辑对象一个实例)和无状态的(所有执行逻辑用一个实例)拦截器。
Spring不支持字段拦截。这是一个经过深思熟虑的设计决定。我总觉得字段拦截不符合封装原则。我更愿意认为AOP是OOP的一个补充而不是与它冲突。在5到10 年后，我们在AOP的学习曲线上走得更远了很自然地会觉得应该在应用程序设计的桌面上给AOP留个位置。(那时像AspectJ 这样的基于语言的解决方案会比今天更具吸引力。)
Spring用动态代理(需要存在一个接口)或运行时CGLIB字节码生成(这使得类的代理成为可能)来实现AOP。这两种方法能在任何应用服务器中运行，也能工作在独立环境中。
Spring是第一个实现了AOP联盟接口(www.sourceforge.net/projects/aopalliance)的AOP框架。这些代表了不同AOP框架的拦截器也许可以协同工作。
Spring集成了AspectJ，提供了将AspectJ 的方面无逢集成到Spring应用程序中的能力。从Spring 1.1 开始已经可以用Spring的IoC容器依赖注入AspectJ 的方面，就像任何Java 类一样。因此AspectJ 的方面可以依赖于任何Spring管理的对象。对即将到来的AspectJ 版本5 的集成更令人激动，基于注释驱动切入点，AspectJ 开始提供用Spring依赖注入任何POJO的能力。
因为Spring拦截的是实例级对象而不是类加载器级的，所以可以在同一个类的不同实例上使用不同的执行逻辑，或把未拦截的对象和已拦截的对象一起使用。
也许Spring AOP的常见用途是用于声明性事务管理。这构建于前面讨论过的事务抽象之上，并且可以用任何POJO 进行声明性事务管理。依靠事务策略，底层机制可以是JTA、JDBC、Hibernate或是其他任何提供事务管理的API。
以下是与EJB CMT的主要不同：
事务管理可以应用于任何POJO。我们建议业务对象实现接口，这只是一个好的编程习惯，不是由框架所强制的。
通过使用Spring的事务API在一个事务性POJO 中实现可编程的回滚。我们为此提供了静态方法，使用ThreadLocal变量，所以你不必传播一个类似EJBContext这样的上下文对象来保证回滚。
文章来源于领测软件测试网 https://www.ltesting.net/
