Spring提供的事务管理可以分为两类：编程式的和声明式的。编程式的，比较灵活，但是代码量大，存在重复的代码比较多;声明式的比编程式的更灵活方便。

      Spring提供的编程式的事务处理

　　Spring提供了几个关于事务处理的类：

　　TransactionDefinition //事务属性定义

TranscationStatus //代表了当前的事务，可以提交，回滚。

TransactionTemplate//Spring提供的事务模板

　　PlatformTransactionManager这个是spring提供的用于管理事务的基础接口，其下有一个实现的抽象类AbstractPlatformTransactionManager，我们使用的事务管理类例如DataSourceTransactionManager等都是这个类的子类。

我们使用编程式的事务管理流程可能如下：

(1) 声明数据源。

(2) 声明一个事务管理类，例如：DataSourceTransactionManager,HibernateTransactionManger,JTATransactionManager等

　　(3) 在我们的代码中加入事务处理代码：

　　TransactionDefinition td = new TransactionDefinition();

　　TransactionStatus ts = transactionManager.getTransaction(td);

　　try{

　　//do sth　transactionManager.commit(ts);

　　}catch(Exception e){transactionManager.rollback(ts);

　　}

　　使用Spring提供的事务模板TransactionTemplate：

　　void add(){

　　transactionTemplate.execute( new TransactionCallback(){

　　public Object doInTransaction(TransactionStatus ts){

　　//do sth}

　　}}

TransactionTemplate也是为我们省去了部分事务提交、回滚代码;定义事务模板时，需注入事务管理对象。

      Spring提供的声明式事务处理

　　Spring声明式事务处理也主要使用了IoC，AOP思想，提供了TransactionInterceptor拦截器和常用的代理类TransactionProxyFactoryBean，可以直接对组件进行事务代理。

　　使用TransactionInterceptor的步骤：
　　（1）定义数据源，事务管理类
　　（2）定义事务拦截器,例如：

　　（3）为组件声明一个代理类：ProxyFactoryBean

　　使用TransactionProxyFactoryBean：

　　TransactionProxyFactoryBean只是为组件的事务代理，如果我们要给组件添加一些业务方面的验证等，可以使用TransactionTemplate加拦截器方式，为组件添加多个拦截器，spring AOP中提供了三类Advice,即前增强，后增强，抛出异常时的增强，可以灵活使用。

Spring Bean 封装机制

Spring 大量引入了Java 的Reflection机制，通过动态调用的方式避免硬编码方式的约束，并在此基础上建立了其核心组件BeanFactory，以此作为其依赖注入机制的实现基础。

org.springframework.beans包中包括了这些核心组件的实现类，核心中的核心为BeanWrapper和BeanFactory类。（对其源码进行研读，必有所获）。BeanFactory家族如图1所示。

图1 BeanFactory家族

BeanWrapper

讲的通俗点，就是在运行期，由Spring根据配置文件，将其他对象的引用通过组件的提供的setter方法进行设定。

通过BeanWrapper，我们可以无需在编码时就指定JavaBean的实现类和属性值，通过在配置文件加以设定，就可以在运行期动态创建对象并设定其属性（依赖关系）。

BeanFactory

Bean Factory，顾名思义，负责创建并维护Bean实例。

Bean Factory负责根据配置文件创建Bean实例，可以配置的项目有：

1． Bean属性值及依赖关系（对其他Bean的引用）

2． Bean创建模式（是否Singleton模式，即是否只针对指定类维持全局唯一的实例）

3． Bean初始化和销毁方法

4． Bean的依赖关系

联合上面关于BeanWrapper的内容，我们可以看到，BeanWrapper实现了针对单个Bean的属性设定操作。而BeanFactory则是针对多个Bean的管理容器，根据给定的配置文件，BeanFactory从中读取类名、属性名/值，然后通过Reflection机制进行Bean加载和属性设定。

ApplicationContext

ApplicationContext覆盖了BeanFactory的所有功能，并提供了更多的特性。此外ApplicationContext为与现有应用框架相整合，提供了更为开放式的实现（如对于Web应用，我们可以在web.xml中对ApplicationContext进行配置）。

相对BeanFactory而言，ApplicationContext提供了以下扩展功能：

1． 国际化支持（MessageSource）

我们可以在Beans.xml文件中，对程序中的语言信息（如提示信息）进行定义，将程序中的提示信息抽取到配置文件中加以定义，为我们进行应用的各语言版本转换提供了极大的灵活性。

2． 资源访问（ResourceLoader）

支持对文件和URL的访问。

3． 事件传播（ApplicationEventPublisher）

事件传播特性为系统中状态改变时的检测提供了良好支持。

4． 多实例加载可以在同一个应用中加载多个Context实例。（ListableBeanFactory）

WebApplicationContext

与ApplicationContext的区别：ApplicationContext均通过编码加载。对于Web应用，Spring提供了可配置的ApplicationContext加载机制。

两种加载器：ContextLoaderServlet , ContextLoaderListener

配置非常简单，在web.xml中增加：

<listener>

    <listener-class>org.springframework.web.context.contextLoaderLisenter</listener-class>

 </listener>

或： 

<servlet>

  <servlet-name>context</servlet-name>     <servlet-class>org.springframework.web.context.contextLoaderServlet</servlet-class>

  <load-on-startup>1</load-on-startup>

</servlet>

通过以 上配置，Web容器会自动加载/WEB-INF/applicationContext.xml初始化ApplicationContext。

 

用白话来讲，就是由容器控制程序之间的关系，而非传统实现中，由程序代码直接操控。这也就是所谓“控制反转”的概念所在：控制权由应用代码中转到了外部容器，控制权的转移，是所谓反转。

DI，

依赖注入的几种实现类型:

1.接口注入

2.构造子注入

3.设值注入

几种依赖注入模式的对比总结

接口注入模式因为具备侵入性，它要求组件必须与特定的接口相关联，因此并不被看好，实际使用有限。

Type2和Type3的依赖注入实现模式均具备无侵入性的特点。在笔者看来，这两种实现方式各有特点，也各具优势（一句经典废话J）。

Type2 构造子注入的优势：

1． “在构造期即创建一个完整、合法的对象”，对于这条Java设计原则，Type2无疑是最好的

响应者。

2． 避免了繁琐的setter方法的编写，所有依赖关系均在构造函数中设定，依赖关系集中呈现，

更加易读。

3． 由于没有setter方法，依赖关系在构造时由容器一次性设定，因此组件在被创建之后即处于相对“不变”的稳定状态，无需担心上层代码在调用过程中执行setter方法对组件依赖关系产生破坏，特别是对于Singleton模式的组件而言，这可能对整个系统产生重大的影响。

4． 同样，由于关联关系仅在构造函数中表达，只有组件创建者需要关心组件内部的依赖关系。对调用者而言，组件中的依赖关系处于黑盒之中。对上层屏蔽不必要的信息，也为系统的层次清晰性提供了保证。

5． 通过构造子注入，意味着我们可以在构造函数中决定依赖关系的注入顺序，对于一个大量依赖外部服务的组件而言，依赖关系的获得顺序可能非常重要，比如某个依赖关系注入的

先决条件是组件的DataSource及相关资源已经被设定。

Type3 设值注入的优势

1． 对于习惯了传统JavaBean开发的程序员而言，通过setter方法设定依赖关系显得更加直

观，更加自然。

2． 如果依赖关系（或继承关系）较为复杂，那么Type2模式的构造函数也会相当庞大（我们需要在构造函数中设定所有依赖关系），此时Type3模式往往更为简洁。

3． 对于某些第三方类库而言，可能要求我们的组件必须提供一个默认的构造函数（如Struts

中的Action），此时Type2类型的依赖注入机制就体现出其局限性，难以完成我们期望的功

能。

注：本文的很多总结来源于对《spring框架，技术详解及使用指导》（作者：夏昕）的学习。