Spring 自 2.0 版本开始，陆续引入了一些注解用于简化 Spring 的开发。@Repository 注解便属于最先引入的一批，它用于将数据访问层 (DAO 层 ) 的类标识为 Spring Bean。具体只需将该注解标注在 DAO 类上即可。同时，为了让 Spring 能够扫描类路径中的类并识别出 @Repository 注解，需要在 XML 配置文件中启用 Bean 的自动扫描功能，这可以通过 <context:component-scan/> 实现。如下所示：

 // 首先使用 @Repository 将 DAO 类声明为 Bean
 package bookstore.dao;
 @Repository
 public class UserDaoImpl implements UserDao{ …… }

 // 其次，在 XML 配置文件中启动 Spring 的自动扫描功能
 <beans … >
    ……
 <context:component-scan base-package=”bookstore.dao” />
……
 </beans>
 

如此，我们就不再需要在 XML 中显式使用 <bean/> 进行 Bean 的配置。Spring 在容器初始化时将自动扫描 base-package 指定的包及其子包下的所有 class 文件，所有标注了 @Repository 的类都将被注册为 Spring Bean。

为什么 @Repository 只能标注在 DAO 类上呢？这是因为该注解的作用不只是将类识别为 Bean，同时它还能将所标注的类中抛出的数据访问异常封装为 Spring 的数据访问异常类型。 Spring 本身提供了一个丰富的并且是与具体的数据访问技术无关的数据访问异常结构，用于封装不同的持久层框架抛出的异常，使得异常独立于底层的框架。

Spring 2.5 在 @Repository 的基础上增加了功能类似的额外三个注解：@Component、@Service、@Constroller，它们分别用于软件系统的不同层次：

•@Component 是一个泛化的概念，仅仅表示一个组件 (Bean) ，可以作用在任何层次。
•@Service 通常作用在业务层，但是目前该功能与 @Component 相同。
•@Constroller 通常作用在控制层，但是目前该功能与 @Component 相同。
通 过在类上使用 @Repository、@Component、@Service 和 @Constroller 注解，Spring 会自动创建相应的 BeanDefinition 对象，并注册到 ApplicationContext 中。这些类就成了 Spring 受管组件。这三个注解除了作用于不同软件层次的类，其使用方式与 @Repository 是完全相同的。

另外，除了上面的四个注解外，用户可以创建自定义的注解，然后在注解上标注 @Component，那么，该自定义注解便具有了与所 @Component 相同的功能。不过这个功能并不常用。

当一个 Bean 被自动检测到时，会根据那个扫描器的 BeanNameGenerator 策略生成它的 bean 名称。默认情况下，对于包含 name 属性的 @Component、@Repository、 @Service 和 @Controller，会把 name 取值作为 Bean 的名字。如果这个注解不包含 name 值或是其他被自定义过滤器发现的组件，默认 Bean 名称会是小写开头的非限定类名。如果你不想使用默认 bean 命名策略，可以提供一个自定义的命名策略。首先实现 BeanNameGenerator 接口，确认包含了一个默认的无参数构造方法。然后在配置扫描器时提供一个全限定类名，如下所示：

 <beans ...>
 <context:component-scan
    base-package="a.b" name-generator="a.SimpleNameGenerator"/>
 </beans>
 

与通过 XML 配置的 Spring Bean 一样，通过上述注解标识的 Bean，其默认作用域是"singleton"，为了配合这四个注解，在标注 Bean 的同时能够指定 Bean 的作用域，Spring 2.5 引入了 @Scope 注解。使用该注解时只需提供作用域的名称就行了，如下所示：

 @Scope("prototype")
 @Repository
 public class Demo { … }
 

如果你想提供一个自定义的作用域解析策略而不使用基于注解的方法，只需实现 ScopeMetadataResolver 接口，确认包含一个默认的没有参数的构造方法。然后在配置扫描器时提供全限定类名：

 <context:component-scan base-package="a.b"
 scope-resolver="footmark.SimpleScopeResolver" />
 

--------------------------------------------------------------------------------

回页首

使用 @PostConstruct 和 @PreDestroy 指定生命周期回调方法

Spring Bean 是受 Spring IoC 容器管理，由容器进行初始化和销毁的（prototype 类型由容器初始化之后便不受容器管理），通常我们不需要关注容器对 Bean 的初始化和销毁操作，由 Spring 经过构造函数或者工厂方法创建的 Bean 就是已经初始化完成并立即可用的。然而在某些情况下，可能需要我们手工做一些额外的初始化或者销毁操作，这通常是针对一些资源的获取和释放操作。 Spring 1.x 为此提供了两种方式供用户指定执行生命周期回调的方法。

第一种方式是实现 Spring 提供的两个接口：InitializingBean 和 DisposableBean。如果希望在 Bean 初始化完成之后执行一些自定义操作，则可以让 Bean 实现 InitializingBean 接口，该接口包含一个 afterPropertiesSet() 方法，容器在为该 Bean 设置了属性之后，将自动调用该方法；如果 Bean 实现了 DisposableBean 接口，则容器在销毁该 Bean 之前，将调用该接口的 destroy() 方法。这种方式的缺点是，让 Bean 类实现 Spring 提供的接口，增加了代码与 Spring 框架的耦合度，因此不推荐使用。

第二种方式是在 XML 文件中使用 <bean> 的 init-method 和 destroy-method 属性指定初始化之后和销毁之前的回调方法，代码无需实现任何接口。这两个属性的取值是相应 Bean 类中的初始化和销毁方法，方法名任意，但是方法不能有参数。示例如下：

 <bean id=”userService”
 class=”bookstore.service.UserService”
 init-method=”init” destroy-method=”destroy”>
    …
 </bean>
 

Spring 2.5 在保留以上两种方式的基础上，提供了对 JSR-250 的支持。JSR-250 规范定义了两个用于指定声明周期方法的注解：@PostConstruct 和 @PreDestroy。这两个注解使用非常简单，只需分别将他们标注于初始化之后执行的回调方法或者销毁之前执行的回调方法上。由于使用了注解，因此需 要配置相应的 Bean 后处理器，亦即在 XML 中增加如下一行：

 <context:annotation-config />
 

比较上述三种指定生命周期回调方法的方式，第一种是不建议使用的，不但其用法不如后两种方式灵活，而且无形中增加了代码与框架的耦合度。后面两种方式开发者可以根据使用习惯选择其中一种，但是最好不要混合使用，以免增加维护的难度。

--------------------------------------------------------------------------------

回页首

使用 @Required 进行 Bean 的依赖检查

依赖检查的作用是，判断给定 Bean 的相应 Setter 方法是否都在实例化的时候被调用了。而不是判断字段是否已经存在值了。Spring 进行依赖检查时，只会判断属性是否使用了 Setter 注入。如果某个属性没有使用 Setter 注入，即使是通过构造函数已经为该属性注入了值，Spring 仍然认为它没有执行注入，从而抛出异常。另外，Spring 只管是否通过 Setter 执行了注入，而对注入的值却没有任何要求，即使注入的 <null/>，Spring 也认为是执行了依赖注入。

<bean> 标签提供了 dependency-check 属性用于进行依赖检查。该属性的取值包括以下几种：

•none -- 默认不执行依赖检查。可以在 <beans> 标签上使用 default-dependency-check 属性改变默认值。
•simple -- 对原始基本类型和集合类型进行检查。
•objects -- 对复杂类型进行检查（除了 simple 所检查类型之外的其他类型）。
•all -- 对所有类型进行检查。
旧 版本使用 dependency-check 在配置文件中设置，缺点是粒度较粗。使用 Spring2.0 提供的 @Required 注解，提供了更细粒度的控制。@Required 注解只能标注在 Setter 方法之上。因为依赖注入的本质是检查 Setter 方法是否被调用了，而不是真的去检查属性是否赋值了以及赋了什么样的值。如果将该注解标注在非 setXxxx() 类型的方法则被忽略。

为了让 Spring 能够处理该注解，需要激活相应的 Bean 后处理器。要激活该后处理器，只需在 XML 中增加如下一行即可。

 <context:annotation-config/>
 

当某个被标注了 @Required 的 Setter 方法没有被调用，则 Spring 在解析的时候会抛出异常，以提醒开发者对相应属性进行设置。

--------------------------------------------------------------------------------

回页首

使用 @Resource、@Autowired 和 @Qualifier 指定 Bean 的自动装配策略

自动装配是指，Spring 在装配 Bean 的时候，根据指定的自动装配规则，将某个 Bean 所需要引用类型的 Bean 注入进来。<bean> 元素提供了一个指定自动装配类型的 autowire 属性，该属性有如下选项：

•no -- 显式指定不使用自动装配。
•byName -- 如果存在一个和当前属性名字一致的 Bean，则使用该 Bean 进行注入。如果名称匹配但是类型不匹配，则抛出异常。如果没有匹配的类型，则什么也不做。
•byType -- 如果存在一个和当前属性类型一致的 Bean ( 相同类型或者子类型 )，则使用该 Bean 进行注入。byType 能够识别工厂方法，即能够识别 factory-method 的返回类型。如果存在多个类型一致的 Bean，则抛出异常。如果没有匹配的类型，则什么也不做。
•constructor -- 与 byType 类似，只不过它是针对构造函数注入而言的。如果当前没有与构造函数的参数类型匹配的 Bean，则抛出异常。使用该种装配模式时，优先匹配参数最多的构造函数。
•autodetect -- 根据 Bean 的自省机制决定采用 byType 还是 constructor 进行自动装配。如果 Bean 提供了默认的构造函数，则采用 byType；否则采用 constructor 进行自动装配。
当 使用 byType 或者 constructor 类型的自动装配的时候，自动装配也支持引用类型的数组或者使用了泛型的集合，这样，Spring 就会检查容器中所有类型匹配的 Bean，组成集合或者数组后执行注入。对于使用了泛型的 Map 类型，如果键是 String 类型，则 Spring 也会自动执行装配，将所有类型匹配的 Bean 作为值，Bean 的名字作为键。

我们可以给 <beans> 增加 default-autowire 属性，设置默认的自动封装策略。默认值为"no"。如果使用自动装配的同时，也指定了 property 或者 constructor-arg 标签，则显式指定的值将覆盖自动装配的值。目前的自动封装不支持简单类型，比如基本类型、String、Class，以及它们的数组类型。

在按类型匹配的时候 ( 可能是 byType、constructor、autodetect)，同一个类型可能存在多个 Bean，如果被注入的属性是数组、集合或者 Map，这可能没有问题，但是如果只是简单的引用类型，则会抛出异常。解决方法有如下几种：

•取消该 Bean 的自动装配特性，使用显式的注入。我们可能不希望某个 Bean 被当作其他 Bean 执行自动封装时的候选对象，我们可以给该 <bean> 增加 autowire-candidate="false"。(autowire-candidate 属性和 autowire 属性相互独立，互不相干。某个 Bean 可以将 autowire-candidate 设置为 false，同时使用 autowire 特性。) 另外，我们可以设置 <beans> 的 default-autowire-candidates 属性，可以在该属性中指定可以用于自动装配候选 Bean 的匹配模式，比如 default-autowire-candidates="*serv,*dao"，这表示所有名字以 serv 或者 dao 结尾的 Bean 被列为候选，其他则忽略，相当于其他 Bean 都指定为 autowire-candidate="false"，此时可以显式为 <bean> 指定 autowire-candidate="true"。在 <bean> 上指定的设置要覆盖 <beans> 上指定的设置。
•如果在多个类型相同的 Bean 中有首选的 Bean，那么可以将该 <bean> 的 primary 属性设置为 "true" ，这样自动装配时便优先使用该 Bean 进行装配。此时不能将 autowire-candidate 设为 false。
•如果使用的是 Java 5 以上版本，可以使用注解进行更细粒度的控制。
使用 @Autowired 和 @Qualifier 注解执行自动装配

使用 @Autowired 注解进行装配，只能是根据类型进行匹配。@Autowired 注解可以用于 Setter 方法、构造函数、字段，甚至普通方法，前提是方法必须有至少一个参数。@Autowired 可以用于数组和使用泛型的集合类型。然后 Spring 会将容器中所有类型符合的 Bean 注入进来。@Autowired 标注作用于 Map 类型时，如果 Map 的 key 为 String 类型，则 Spring 会将容器中所有类型符合 Map 的 value 对应的类型的 Bean 增加进来，用 Bean 的 id 或 name 作为 Map 的 key。

@Autowired 标注作用于普通方法时，会产生一个副作用，就是在容器初始化该 Bean 实例的时候就会调用该方法。当然，前提是执行了自动装配，对于不满足装配条件的情况，该方法也不会被执行。

当标注了 @Autowired 后，自动注入不能满足，则会抛出异常。我们可以给 @Autowired 标注增加一个 required=false 属性，以改变这个行为。另外，每一个类中只能有一个构造函数的 @Autowired.required() 属性为 true。否则就出问题了。如果用 @Autowired 同时标注了多个构造函数，那么，Spring 将采用贪心算法匹配构造函数 ( 构造函数最长 )。

@Autowired 还有一个作用就是，如果将其标注在 BeanFactory 类型、ApplicationContext 类型、ResourceLoader 类型、ApplicationEventPublisher 类型、MessageSource 类型上，那么 Spring 会自动注入这些实现类的实例，不需要额外的操作。

当容器中存在多个 Bean 的类型与需要注入的相同时，注入将不能执行，我们可以给 @Autowired 增加一个候选值，做法是在 @Autowired 后面增加一个 @Qualifier 标注，提供一个 String 类型的值作为候选的 Bean 的名字。举例如下：

 @Autowired(required=false)
 @Qualifier("ppp")
 public void setPerson(person p){}
 

@Qualifier 甚至可以作用于方法的参数 ( 对于方法只有一个参数的情况，我们可以将 @Qualifer 标注放置在方法声明上面，但是推荐放置在参数前面 )，举例如下：

 @Autowired(required=false)
 public void sayHello(@Qualifier("ppp")Person p,String name){}
 

我们可以在配置文件中指定某个 Bean 的 qualifier 名字，方法如下：

 <bean id="person" class="footmark.spring.Person">
    <qualifier value="ppp"/>
 </bean>
 

如果没有明确指定 Bean 的 qualifier 名字，那么默认名字就是 Bean 的名字。通常，qualifier 应该是有业务含义的，例如 "domain"，"persistent" 等，而不应该是类似 "person" 方式。

我们还可以将 @Qualifier 标注在集合类型上，那么所有 qualifier 名字与指定值相同的 Bean 都将被注入进来。

最后，配置文件中需要指定每一个自定义注解的属性值。我们可以使用 <meta> 标签来代替 <qualifier/> 标签，如果 <meta> 标签和 <qualifier/> 标签同时出现，那么优先使用 <qualifier> 标签。如果没有 <qualifier> 标签，那么会用 <meta> 提供的键值对来封装 <qualifier> 标签。示例如下：

 <bean class="footmark.HelloWorld">
 <qualifier type="MovieQualifier">
 <attribute key="format" value="VHS"/>
 <attribute key="genre" value="Comedy"/>
 </qualifier>
 </bean>
 <bean class="footmark.HelloWorld">
 <meta key="format" value="DVD"/>
 <meta key="genre" value="Action"/>
 </bean>
 

@Autowired 注解对应的后处理注册与前面相似，只需在配置文件中增加如下一行即可：

 <context:annotation-config/>
 

如果 @Autowired 注入的是 BeanFactory、ApplicationContext、ResourceLoader 等系统类型，那么则不需要 @Qualifier，此时即使提供了 @Qualifier 注解，也将会被忽略；而对于自定义类型的自动装配，如果使用了 @Qualifier 注解并且没有名字与之匹配的 Bean，则自动装配匹配失败。

使用 JSR-250 中的 @Resource 和 @Qualifier 注解

如果希望根据 name 执行自动装配，那么应该使用 JSR-250 提供的 @Resource 注解，而不应该使用 @Autowired 与 @Qualifier 的组合。

@Resource 使用 byName 的方式执行自动封装。@Resource 标注可以作用于带一个参数的 Setter 方法、字段，以及带一个参数的普通方法上。@Resource 注解有一个 name 属性，用于指定 Bean 在配置文件中对应的名字。如果没有指定 name 属性，那么默认值就是字段或者属性的名字。@Resource 和 @Qualifier 的配合虽然仍然成立，但是 @Qualifier 对于 @Resource 而言，几乎与 name 属性等效。

如果 @Resource 没有指定 name 属性，那么使用 byName 匹配失败后，会退而使用 byType 继续匹配，如果再失败，则抛出异常。在没有为 @Resource 注解显式指定 name 属性的前提下，如果将其标注在 BeanFactory 类型、ApplicationContext 类型、ResourceLoader 类型、ApplicationEventPublisher 类型、MessageSource 类型上，那么 Spring 会自动注入这些实现类的实例，不需要额外的操作。此时 name 属性不需要指定 ( 或者指定为"")，否则注入失败；如果使用了 @Qualifier，则该注解将被忽略。而对于用户自定义类型的注入，@Qualifier 和 name 等价，并且不被忽略。

<bean> 的 primary 和 autowire-candidate 属性对 @Resource、@Autowired 仍然有效。

--------------------------------------------------------------------------------

回页首

使用 @Configuration 和 @Bean 进行 Bean 的声明

虽然 2.0 版本发布以来，Spring 陆续提供了十多个注解，但是提供的这些注解只是为了在某些情况下简化 XML 的配置，并非要取代 XML 配置方式。这一点可以从 Spring IoC 容器的初始化类可以看出：ApplicationContext 接口的最常用的实现类是 ClassPathXmlApplicationContext 和 FileSystemXmlApplicationContext，以及面向 Portlet 的 XmlPortletApplicationContext 和面向 web 的 XmlWebApplicationContext，它们都是面向 XML 的。Spring 3.0 新增了另外两个实现类：AnnotationConfigApplicationContext 和 AnnotationConfigWebApplicationContext。从名字便可以看出，它们是为注解而生，直接依赖于注解作为容器配置信息来 源的 IoC 容器初始化类。由于 AnnotationConfigWebApplicationContext 是 AnnotationConfigApplicationContext 的 web 版本，其用法与后者相比几乎没有什么差别，因此本文将以 AnnotationConfigApplicationContext 为例进行讲解。

AnnotationConfigApplicationContext 搭配上 @Configuration 和 @Bean 注解，自此，XML 配置方式不再是 Spring IoC 容器的唯一配置方式。两者在一定范围内存在着竞争的关系，但是它们在大多数情况下还是相互协作的关系，两者的结合使得 Spring IoC 容器的配置更简单，更强大。

之前，我们将配置信息集中写在 XML 中，如今使用注解，配置信息的载体由 XML 文件转移到了 Java 类中。我们通常将用于存放配置信息的类的类名以 “Config” 结尾，比如 AppDaoConfig.java、AppServiceConfig.java 等等。我们需要在用于指定配置信息的类上加上 @Configuration 注解，以明确指出该类是 Bean 配置的信息源。并且 Spring 对标注 Configuration 的类有如下要求：

•配置类不能是 final 的；
•配置类不能是本地化的，亦即不能将配置类定义在其他类的方法内部；
•配置类必须有一个无参构造函数。
AnnotationConfigApplicationContext 将配置类中标注了 @Bean 的方法的返回值识别为 Spring Bean，并注册到容器中，受 IoC 容器管理。@Bean 的作用等价于 XML 配置中的 <bean/> 标签。示例如下：

 @Configuration
 public class BookStoreDaoConfig{
    @Bean
    public UserDao userDao(){ return new UserDaoImpl();}
    @Bean
    public BookDao bookDao(){return new BookDaoImpl();}
 }
 

Spring 在解析到以上文件时，将识别出标注 @Bean 的所有方法，执行之，并将方法的返回值 ( 这里是 UserDaoImpl 和 BookDaoImpl 对象 ) 注册到 IoC 容器中。默认情况下，Bean 的名字即为方法名。因此，与以上配置等价的 XML 配置如下：

 <bean id=”userDao” class=”bookstore.dao.UserDaoImpl”/>
 <bean id=”bookDao” class=”bookstore.dao.BookDaoImpl”/>
 

@Bean 具有以下四个属性：

•name -- 指定一个或者多个 Bean 的名字。这等价于 XML 配置中 <bean> 的 name 属性。
•initMethod -- 容器在初始化完 Bean 之后，会调用该属性指定的方法。这等价于 XML 配置中 <bean> 的 init-method 属性。
•destroyMethod -- 该属性与 initMethod 功能相似，在容器销毁 Bean 之前，会调用该属性指定的方法。这等价于 XML 配置中 <bean> 的 destroy-method 属性。
•autowire -- 指定 Bean 属性的自动装配策略，取值是 Autowire 类型的三个静态属性。Autowire.BY_NAME，Autowire.BY_TYPE，Autowire.NO。与 XML 配置中的 autowire 属性的取值相比，这里少了 constructor，这是因为 constructor 在这里已经没有意义了。
@Bean 没有直接提供指定作用域的属性，可以通过 @Scope 来实现该功能，关于 @Scope 的用法已在上文列举。

下面讲解基于注解的容器初始化。AnnotationConfigApplicationContext 提供了三个构造函数用于初始化容器。

•AnnotationConfigApplicationContext()：该构造函数初始化一个空容器，容器不包含任何 Bean 信息，需要在稍后通过调用其 register() 方法注册配置类，并调用 refresh() 方法刷新容器。
•AnnotationConfigApplicationContext(Class<?>... annotatedClasses)：这是最常用的构造函数，通过将涉及到的配置类传递给该构造函数，以实现将相应配置类中的 Bean 自动注册到容器中。
•AnnotationConfigApplicationContext(String... basePackages)：该构造函数会自动扫描以给定的包及其子包下的所有类，并自动识别所有的 Spring Bean，将其注册到容器中。它不但识别标注 @Configuration 的配置类并正确解析，而且同样能识别使用 @Repository、@Service、@Controller、@Component 标注的类。
除了使用上面第三种类型的构造函数让容器 自动扫描 Bean 的配置信息以外，AnnotationConfigApplicationContext 还提供了 scan() 方法，其功能与上面也类似，该方法主要用在容器初始化之后动态增加 Bean 至容器中。调用了该方法以后，通常需要立即手动调用 refresh() 刷新容器，以让变更立即生效。

需要注意的是，AnnotationConfigApplicationContext 在解析配置类时，会将配置类自身注册为一个 Bean，因为 @Configuration 注解本身定义时被 @Component 标注了。因此可以说，一个 @Configuration 同时也是一个 @Component。大多数情况下，开发者用不到该 Bean，并且在理想情况下，该 Bean 应该是对开发者透明的。@Configuration 的定义如下所示：

 @Target({ElementType.TYPE})
 @Retention(RetentionPolicy.RUNTIME)
 @Documented
 @Component
 public @interface Configuration {
 String value() default "";
 }
 

在一般的项目中，为了结构清晰，通常会根据软件的模块或者结构定义多个 XML 配置文件，然后再定义一个入口的配置文件，该文件使用 <import/> 将其他的配置文件组织起来。最后只需将该文件传给 ClassPathXmlApplicationContext 的构造函数即可。针对基于注解的配置，Spring 也提供了类似的功能，只需定义一个入口配置类，并在该类上使用 @Import 注解引入其他的配置类即可，最后只需要将该入口类传递给 AnnotationConfigApplicationContext。具体示例如下：

 @Configuration
 @Import({BookStoreServiceConfig.class,BookStoreDaoConfig.class})
 public class BookStoreConfig{ … }
 

--------------------------------------------------------------------------------

回页首

混合使用 XML 与注解进行 Bean 的配置

设计 @Configuration 和 @Bean 的初衷，并不是为了完全取代 XML，而是为了在 XML 之外多一种可行的选择。由于 Spring 自发布以来，Spring 开发小组便不断简化 XML 配置，使得 XML 配置方式已经非常成熟，加上 Spring 2.0 以后出现了一系列命名空间的支持，使得 XML 配置方式成为了使用简单、功能强大的 Bean 定义方式。而且，XML 配置的一些高级功能目前还没有相关注解能够直接支持。因此，在目前的多数项目中，要么使用纯粹的 XML 配置方式进行 Bean 的配置，要么使用以注解为主，XML 为辅的配置方式进行 Bean 的配置。

之所以会出现两者共存的情况，主要归结为三个原因：其一，目前绝大多数采用 Spring 进行开发的项目，几乎都是基于 XML 配置方式的，Spring 在引入注解的同时，必须保证注解能够与 XML 和谐共存，这是前提；其二，由于注解引入较晚，因此功能也没有发展多年的 XML 强大，因此，对于复杂的配置，注解还很难独当一面，在一段时间内仍然需要 XML 的配合才能解决问题。除此之外，Spring 的 Bean 的配置方式与 Spring 核心模块之间是解耦的，因此，改变配置方式对 Spring 的框架自身是透明的。Spring 可以通过使用 Bean 后处理器 (BeanPostProcessor) 非常方便的增加对于注解的支持。这在技术实现上非常容易的事情。

要使用混合配置方式，首先需要判断以哪一种配置方式为主。对这个问题的不同回答将会直接影响到实现的方式。然而大可不必为此伤脑筋，因为不论是以 XML 为主，还是以注解为主，配置方式都是简单而且容易理解的。这里不存在错误的决定，因为仅仅是表现方式不一样。我们首先假设以 XML 配置为主的情况。

对于已经存在的大型项目，可能初期是以 XML 进行 Bean 配置的，后续逐渐加入了注解的支持，这时我们只需在 XML 配置文件中将被 @Configuration 标注的类定义为普通的 <bean>，同时注册处理注解的 Bean 后处理器即可。示例如下：

 // 假设存在如下的 @Configuration 类：
 package bookstore.config;
 import bookstore.dao.*;
 @Configuration
 public class MyConfig{
 @Bean
    public UserDao userDao(){
        return new UserDaoImpl();
    }
 }
此时，只需在 XML 中作如下声明即可：
 <beans … >
    ……
    <context:annotation-config />
    <bean class=”demo.config.MyConfig”/>
 </beans>
 

由于启用了针对注解的 Bean 后处理器，因此在 ApplicationContext 解析到 MyConfig 类时，会发现该类标注了 @Configuration 注解，随后便会处理该类中标注 @Bean 的方法，将这些方法的返回值注册为容器总的 Bean。

对于以上的方式，如果存在多个标注了 @Configuration 的类，则需要在 XML 文件中逐一列出。另一种方式是使用前面提到的自动扫描功能，配置如下：

 <context:component-scan base-package=”bookstore.config” />
 

如此，Spring 将扫描所有 demo.config 包及其子包中的类，识别所有标记了 @Component、@Controller、@Service、@Repository 注解的类，由于 @Configuration 注解本身也用 @Component 标注了，Spring 将能够识别出 @Configuration 标注类并正确解析之。

对于以注解为中心的配置方式，只需使用 @ImportResource 注解引入存在的 XML 即可，如下所示：

Caused by: java.lang.IllegalArgumentException: Cannot convert value of type [$Proxy5 implementing java.lang.Runnable,org.springframework.aop.SpringProxy,org.springframework.aop.framework.Advised] to required type [java.util.TimerTask] for property 'timerTask': no matching editors or conversion strategy found
    at org.springframework.beans.TypeConverterDelegate.convertIfNecessary(TypeConverterDelegate.java:231)
    at org.springframework.beans.TypeConverterDelegate.convertIfNecessary(TypeConverterDelegate.java:138)
    at org.springframework.beans.BeanWrapperImpl.convertForProperty(BeanWrapperImpl.java:386)
     42 more

错误为:

原因为:

缺少包：cglib-2.1.3.jar

1，Version版本号

2，时间戳

3，自动版本控制。

这里不建议在新的应用程序中定义没有版本或者时间戳列的版本控制：它更慢，更复杂，如果你正在使用脱管对象，它则不会生效。

以下信息来自 : http://esffor.javaeye.com/blog/168243

通过在表中及POJO中增加一个version字段来表示记录的版本，来达到多用户同时更改一条数据的冲突

数据库脚本： 

create table studentVersion (id varchar(32),name varchar(32),ver int);

POJO

package Version;

public class Student {
  private String id;
  private String name;
  private int version;
public String getId() {
    return id;
}
public void setId(String id) {
    this.id = id;
}
public String getName() {
    return name;
}
public void setName(String name) {
    this.name = name;
}
public int getVersion() {
    return version;
}
public void setVersion(int version) {
    this.version = version;
}


}

Student.hbm.xml

<?xml version="1.0" encoding="utf-8"?>
<!DOCTYPE hibernate-mapping PUBLIC "-//Hibernate/Hibernate Mapping DTD 3.0//EN"
"http://hibernate.sourceforge.net/hibernate-mapping-3.0.dtd">
<!-- 
    Mapping file autogenerated by MyEclipse - Hibernate Tools
-->
<hibernate-mapping>
<class name="Version.Student" table="studentVersion" >
    <id name="id" unsaved-value="null">
      <generator class="uuid.hex"></generator>
    </id>
    <!--version标签必须跟在id标签后面-->
    <version name="version" column="ver" type="int"></version>
    <property name="name" type="string" column="name"></property>  
</class>

</hibernate-mapping>

Hibernate.cfg.xml

<?xml version='1.0' encoding='UTF-8'?>
<!DOCTYPE hibernate-configuration PUBLIC
          "-//Hibernate/Hibernate Configuration DTD 3.0//EN"
          "http://hibernate.sourceforge.net/hibernate-configuration-3.0.dtd">

<!-- Generated by MyEclipse Hibernate Tools.                   -->
<hibernate-configuration>

<session-factory>
    <property name="connection.username">root</property>
    <property name="connection.url">
        jdbc:mysql://localhost:3306/schoolproject?characterEncoding=gb2312&amp;useUnicode=true
    </property>
    <property name="dialect">
        org.hibernate.dialect.MySQLDialect
    </property>
    <property name="myeclipse.connection.profile">mysql</property>
    <property name="connection.password">1234</property>
    <property name="connection.driver_class">
        com.mysql.jdbc.Driver
    </property>
    <property name="hibernate.dialect">
        org.hibernate.dialect.MySQLDialect
    </property>
    <property name="hibernate.show_sql">true</property>
    <property name="current_session_context_class">thread</property>
    <property name="jdbc.batch_size">15</property>
    <mapping resource="Version/Student.hbm.xml" />




</session-factory>

</hibernate-configuration>

测试代码：

package Version;


import java.io.File;
import java.util.Iterator;
import java.util.Set;

import org.hibernate.Session;
import org.hibernate.SessionFactory;
import org.hibernate.Transaction;
import org.hibernate.cfg.Configuration;

public class Test {


    public static void main(String[] args) {

        String filePath=System.getProperty("user.dir")+File.separator+"src/Version"+File.separator+"hibernate.cfg.xml";
        File file=new File(filePath);
        System.out.println(filePath);
        SessionFactory sessionFactory=new Configuration().configure(file).buildSessionFactory();
        Session session=sessionFactory.openSession();
        Transaction t=session.beginTransaction();
        
        Student stu=new Student();
        stu.setName("tom11");
        session.save(stu);
        t.commit();
      
        
        /*
         * 模拟多个session操作student数据表
         */
        
        Session session1=sessionFactory.openSession();
        Session session2=sessionFactory.openSession();
        Student stu1=(Student)session1.createQuery("from Student s where s.name='tom11'").uniqueResult();
        Student stu2=(Student)session2.createQuery("from Student s where s.name='tom11'").uniqueResult();
        
        //这时候，两个版本号是相同的
        System.out.println("v1="+stu1.getVersion()+"--v2="+stu2.getVersion());
        
        Transaction tx1=session1.beginTransaction();
        stu1.setName("session1");
        tx1.commit();
        //这时候，两个版本号是不同的，其中一个的版本号递增了
        System.out.println("v1="+stu1.getVersion()+"--v2="+stu2.getVersion());
        
        Transaction tx2=session2.beginTransaction();
        stu2.setName("session2");
        tx2.commit();
        
        
        
    }

}

运行结果：

Hibernate: insert into studentVersion (ver, name, id) values (?, ?, ?)
Hibernate: select student0_.id as id0_, student0_.ver as ver0_, student0_.name as name0_ from studentVersion student0_ where student0_.name='tom11'
Hibernate: select student0_.id as id0_, student0_.ver as ver0_, student0_.name as name0_ from studentVersion student0_ where student0_.name='tom11'
v1=0--v2=0
Hibernate: update studentVersion set ver=?, name=? where id=? and ver=?
v1=1--v2=0
Hibernate: update studentVersion set ver=?, name=? where id=? and ver=?
Exception in thread "main" org.hibernate.StaleObjectStateException: Row was updated or deleted by another transaction (or unsaved-value mapping was incorrect): [Version.Student#4028818316cd6b460116cd6b50830001]

可以看到，第二个“用户”session2修改数据时候，记录的版本号已经被session1更新过了，所以抛出了红色的异常，我们可以在实际应用 中处理这个异常，例如在处理中重新读取数据库中的数据，同时将目前的数据与数据库中的数据展示出来，让使用者有机会比较一下，或者设计程序自动读取新的数 据

注意：

    要注意的是，由于乐观锁定是使用系统中的程式来控制，而不是使用资料库中的锁定机制，因而如果有人特意自行更新版本讯息来越过检查，则锁定机制就会无效，例如在上例中自行更改stu的version属性，使之与资料库中的版本号相同的话就不会有错误，像这样版本号被更改，或是由于资料是由外部系统而来，因而版本资讯不受控制时，锁定机制将会有问题，设计时必须注意。

    如果手工设置stu.setVersion()自行更新版本以跳过检查,则这种乐观锁就会失效，应对方法可以将Student.java的setVersion设置成private

Caught exception while loading file struts-default.xml - [unknown location]

at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadConfigurationFiles(XmlConfigurationProvider.java:839)

at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.loadDocuments(XmlConfigurationProvider.java:131)

at com.opensymphony.xwork2.config.providers.XmlConfigurationProvider.init(XmlConfigurationProvider.java:100)

……………………………………

现象: 第一次能运行, reload就不行.

试了Struts2自带的blank包, 没问题.

那基本可断定是其他jar包有冲突, 应该是XML解析包有冲突.

检查发布后的WEB-INF/lib有两个XML解析包: xml-apis.jar和xerces-2.6.2.jar

这种错误真正原因不是JDK 6和Struts 2冲突, 而是 MyEclipse Hibernate 类库中多了两个包: xml-apis.jar和xerces-2.6.2.jar, 这两个包的功能和JDK的冲突了. 解决办法: 1. 删除发布后目录的 WEB-INF/lib/ 下的这两个文件; 2. 或者使用JDK 1.5来启动Tomcat 6.

  getCurrentSession创建的线程会在事务回滚或事物提交后自动关闭,而openSession必须手动关闭

         这里getCurrentSession本地事务(本地事务:jdbc)时 要在配置文件里进行如下设置

         如果使用的是本地事务（jdbc事务）
            <property name="hibernate.current_session_context_class">thread</property>
         如果使用的是全局事务（jta事务）
            <property name="hibernate.current_session_context_class">jta</property> 

   getCurrentSession ()使用当前的session，openSession()重新建立一个新的session

   在一个应用程序中，如果DAO 层使用Spring 的hibernate 模板，通过Spring 来控制session 的生命周期，则首选getCurrentSession ()。

   使用Hibernate的大多数应用程序需要某种形式的“上下文相关的” session，特定的session在整个特定的上下文范围内始终有效。然而，对不同类型的应用程序而言，要为什么是组成这种“上下文”下一个定义通常 是困难的；不同的上下文对“当前”这个概念定义了不同的范围。在3.0版本之前，使用Hibernate的程序要么采用自行编写的基于 ThreadLocal的上下文session，要么采用HibernateUtil这样的辅助类，要么采用第三方框架（比如Spring或Pico)， 它们提供了基于代理(proxy)或者基于拦截器(interception)的上下文相关session。

   从3.0.1版本开 始，Hibernate增加了SessionFactory.getCurrentSession()方法。一开始，它假定了采用JTA事务，JTA事务 定义了当前session的范围和上下文(scope and context)。Hibernate开发团队坚信，因为有好几个独立的JTA TransactionManager实现稳定可用，不论是否被部署到一个J2EE容器中，大多数(假若不是所有的）应用程序都应该采用JTA事务管理。 基于这一点，采用JTA的上下文相关session可以满足你一切需要。

   更好的是，从3.1开 始，SessionFactory.getCurrentSession()的后台实现是可拔插的。因此，我们引入了新的扩展接口 (org.hibernate.context.CurrentSessionContext)和新的配置参数 (hibernate.current_session_context_class)，以便对什么是“当前session”的范围和上下文(scope and context)的定义进行拔插。

   请参阅 org.hibernate.context.CurrentSessionContext接口的Javadoc,那里有关于它的契约的详细讨论。它定义 了单一的方法，currentSession()，特定的实现用它来负责跟踪当前的上下文session。Hibernate内置了此接口的两种实现。

   org.hibernate.context.JTASessionContext - 当前session根据JTA来跟踪和界定。这和以前的仅支持JTA的方法是完全一样的。详情请参阅Javadoc。

   org.hibernate.context.ThreadLocalSessionContext - 当前session通过当前执行的线程来跟踪和界定。详情也请参阅Javadoc。

   这两种实现都提供了“每数据库事务对应一个session”的编程模型，也称作每次请求一个session。Hibernate session的起始和终结由数据库事务的生存来控制。假若你采用自行编写代码来管理事务（比如，在纯粹的J2SE,或者 JTA/UserTransaction/BMT），建议你使用Hibernate Transaction API来把底层事务实现从你的代码中隐藏掉。如果你在支持CMT的EJB容器中执行，事务边界是声明式定义的，你不需要在代码中进行任何事务或 session管理操作。请参阅第 11 章 事务和并发一节来阅读更多的内容和示例代码。

   hibernate.current_session_context_class 配置参数定义了应该采用哪个          

   org.hibernate.context.CurrentSessionContext实现。注意，为了向下兼容，如果未 配置此参数，但是存在 

   org.hibernate.transaction.TransactionManagerLookup的配 置，Hibernate会采用 

   org.hibernate.context.JTASessionContext。一般而言，此参数的值指明了要使用的实 现类的全名，但那两个内置的实现可以使用简写，即"jta"和"thread"。

                                利于ThreadLocal模式管理Session
   早在Java1.2推出之时，Java平台中就引入了一个新的支持：java.lang.ThreadLocal，给我们在编写多线程程序
   时提供了一种新的选择。ThreadLocal是什么呢？其实ThreadLocal并非是一个线程的本地实现版本，它并不是一个Thread，
   而是thread local variable(线程局部变量)。也许把它命名为ThreadLocalVar更加合适。线程局部变量(ThreadLocal)
   其实的功用非常简单，就是为每一个使用某变量的线程都提供一个该变量值的副本，是每一个线程都可以独立地改变自己的副本，
   而不会和其它线程的副本冲突。从线程的角度看，就好像每一个线程都完全拥有一个该变量。
   ThreadLocal是如何做到为每一个线程维护变量的副本的呢？其实实现的思路很简单，在ThreadLocal类中有一个Map，
   用于存储每一个线程的变量的副本。比如下面的示例实现(为了简单，没有考虑集合的泛型)：
public class HibernateUtil {

public static final ThreadLocal session =new ThreadLocal();

public static final SessionFactory sessionFactory;
   static {
      try {
        sessionFactory = new Configuration().configure().buildSessionFactory();
      } catch (Throwable ex) {
           throw new ExceptionInInitializerError(ex);
      }    
}

     public static Session currentSession() throws HibernateException {
        Session s = session.get();
        if(s == null) {
          s = sessionFactory.openSession();
          session.set(s);
           }
         return s;
       }

    public static void closeSession() throws HibernateException {
           Session s = session.get();
        if(s != null) {
            s.close();
        }
        session.set(null);
    }
}

openSession() 与 getCurrentSession() 有何不同和关联呢？

   在 SessionFactory 启动的时候， Hibernate 会根据配置创建相应的 CurrentSessionContext ，在 getCurrentSession() 被调用的时候，实际被执行的方法是 CurrentSessionContext.currentSession() 。在 currentSession() 执行时，如果当前 Session 为空， currentSession 会调用 SessionFactory 的 openSession 。所以 getCurrentSession() 对于 Java EE 来说是更好的获取 Session 的方法。

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/LoveYouT/archive/2009/05/17/4193894.aspx

文件struts-config.xml :

<action-mappings>
  <action attribute="userloginForm" input="/login.jsp"
   name="userloginForm" parameter="method" path="/userlogin"
   scope="request" validate="true"
   type="cn.userlogin.struts.action.UserloginAction" />

 </action-mappings>
 <message-resources
  parameter="cn.userlogin.struts.ApplicationResources" />
 <plug-in className="org.apache.struts.validator.ValidatorPlugIn">
  <set-property property="pathnames" value="/WEB-INF/validator-rules.xml,/WEB-INF/validation.xml" />
 </plug-in>

1．用Javascript在客户端进行验证
配置：在需要验证的JSP文件中写入

<html:form action="/XXX" onsubmit="return validateXXXX(this);">
这里的XXX 是与要进行验证的 forward name
validateXXXX (this);里面的XXXX是需要进行验证的ActionForm名

<html:javascript formName="mytestForm"/>

在validation.xml文件中写入验证代码就可以进行基本的验证了。具体请参照http://www.chinajavaworld.net/forum/topic.cgi?forum=48&topic=1413&show=50

这种方法是在客户端进行验证，客户端可以看到JAVASCRIPT部分的全代码。安全性不高

2．使自己的ActionForm继承ValidatorForm类，在里面编写自己的方法：
public ActionErrors validate (ActionMapping mapping,HttpServletRequest request) {

        ActionErrors errors = new ActionErrors();

。。。。。。
if ( mytext.equals("aaa") ) {                    //my example
       errors.add("mytext",new ActionError("mytext.error"));
}
。。。。。。
return errors;

}
此时，如果写了这个方法，就会屏蔽掉在Validation.xml中定义的验证部分，换句话说就是系统运行时，Validation.xml里对应此ActionForm的定义的错误验证部分不实行
如果不写这个方法的话，系统运行时会进行Validation.xml里对应此ActionForm的定义的错误验证部分的操作

此类方法是在服务器端进行验证，验证部分代码客户端不可见。

3．动态验证DynaValidatorForm的使用
  不需要再写对应的ActionForm，只需在struts-config.xml里把自己的ActionForm进行配置

    <form-bean      name="testForm"
        type="org.apache.struts.validator.DynaValidatorForm">
       <form-property name="mytext" type="java.lang.String"/>
       <form-property name="mytextarea" type="java.lang.String"/>
       <form-property name="mydatetext" type="java.lang.String"/>
    </form-bean>

在form-property里设置相应的项目，比如说mytext，mytextarea什么的，执行的时候会动态生成ActionForm

   再在validation.xml里写入所希望的验证代码，就可以了

JSP文件里不需要写入任何东西，验证也是在服务器端进行，验证部分代码在JSP中不可见

4．组合验证
如果使用动态验证DynaValidatorForm的话，不许编写自己的对应的ActionForm，相应的特殊验证会受到相当程度的限制。

这个时候，需要将特殊验证部分写入对应的Action，

if(mytext.equals("aaa")){                    //My Example
ActionErrors errors = new ActionErrors();
errors.add("***",new ActionError("***.error"));      
saveErrors(request,errors);return (mapping.findForward("false"));
}

我们知道Spring通过各种DAO模板类降低了研发者使用各种数据持久技术的难度。这些模板类都是线程安全的，也就是说，多个DAO能够复用同一个模板实例而不会发生冲突。

我们使用模板类访问底层数据，根据持久化技术的不同，模板类需要绑定数据连接或会话的资源。但这些资源本身是非线程安全的，也就是说他们不能在同一时刻被多个线程共享。

虽然模板类通过资源池获取数据连接或会话，但资源池本身解决的是数据连接或会话的缓存问题，并非数据连接或会话的线程安全问题。

按照传统经验，假如某个对象是非线程安全的，在多线程环境下，对对象的访问必须采用synchronized进行线程同步。但Spring的DAO模板类并未采用线程同步机制，因为线程同步限制了并发访问，会带来很大的性能损失。

此外，通过代码同步解决性能安全问题挑战性很大，可能会增强好几倍的实现难度。那模板类究竟仰丈何种魔法神功，能够在无需同步的情况下就化解线程安全的难题呢？答案就是ThreadLocal！

ThreadLocal在Spring中发挥着重要的作用，在管理request作用域的Bean、事务管理、任务调度、AOP等模块都出现了他们的身影，起着举足轻重的作用。要想了解Spring事务管理的底层技术，ThreadLocal是必须攻克的山头堡垒。

ThreadLocal是什么

早在JDK 1.2的版本中就提供java.lang.ThreadLocal，ThreadLocal为解决多线程程式的并发问题提供了一种新的思路。使用这个工具类能够很简洁地编写出优美的多线程程式。

ThreadLocal很容易让人望文生义，想当然地认为是个“本地线程”。其实，ThreadLocal并不是个Thread，而是Thread的局部变量，也许把他命名为ThreadLocalVariable更容易让人理解一些。

当使用ThreadLocal维护变量时，ThreadLocal为每个使用该变量的线程提供单独的变量副本，所以每一个线程都能够单独地改变自己的副本，而不会影响其他线程所对应的副本。

从线程的角度看，目标变量就象是线程的本地变量，这也是类名中“Local”所要表达的意思。

线程局部变量并不是Java的新发明，很多语言（如IBM IBM XL FORTRAN）在语法层面就提供线程局部变量。在Java中没有提供在语言级支持，而是变相地通过ThreadLocal的类提供支持。

所以，在Java中编写线程局部变量的代码相对来说要笨拙一些，因此造成线程局部变量没有在Java研发者中得到很好的普及。

ThreadLocal的接口方法

ThreadLocal类接口很简单，只有4个方法，我们先来了解一下：

    * void set(Object value)

配置当前线程的线程局部变量的值。

    * public Object get()

该方法返回当前线程所对应的线程局部变量。

    * public void remove()

将当前线程局部变量的值删除，目的是为了减少内存的占用，该方法是JDK 5.0新增的方法。需要指出的是，当线程结束后，对应该线程的局部变量将自动被垃圾回收，所以显式调用该方法清除线程的局部变量并不是必须的操作，但他能够加快内存回收的速度。

    * protected Object initialValue()

返回该线程局部变量的初始值，该方法是个protected的方法，显然是为了让子类覆盖而设计的。这个方法是个延迟调用方法，在线程第1次调用get()或set(Object)时才执行，并且仅执行1次。ThreadLocal中的缺省实现直接返回一个null。

Spring是一个强大的Java应用框架，它广泛地应用于Java应用程序中，为Plain Old Java Objects（POJO）提供企业级服务。Spring利用依赖注入机制来简化工作，同时提高可测试性。其配置文件（通常是XML格式）中指定了Spring bean、依赖性以及bean所需的服务。但是，这些XML配置文件既冗长又不实用。对于需要定义大量Spring bean的大型项目来说，它们难以阅读和管理。
在本文中，我将向您展示12种用于Spring XML配置的最佳实践。其中的一些实践与其说是最佳实践，倒不如说是必要实践。注意，其他因素（如域模型的设置）也可能影响XML的配置，但是本文重点研究XML配置的可读性和可管理性。

1。避免使用自动绑定（autowiring）功能
Spring可以通过bean类的自省自动绑定依赖性，所以不必显式指明bean的属性和构造函数。Bean属性可以通过属性名称或类型匹配来实现自动绑定。构造函数通过类型匹配来实现自动绑定。甚至可以指定自动检测autowiring模式，它可以引导Spring选择一种适当的运行机制。先来看看下面的一个例子：
    <bean id="orderService"
        class="com.lizjason.spring.OrderService"
        autowire="byName"/>
OrderService类的属性名在容器中用于匹配bean实例。自动绑定可能会节省一些键入工作量并减少混乱。但是在现实项目中不应该使用这种方式，因为它牺牲了配置的可读性和可维护性。许多指南和介绍中大肆吹捧自动绑定是Spring的一项极好的特性，而没有提到这一特性所带来的牺牲。依我来看，这就像Spring中的对象池（object－pooling），更大程度上只是宣传的噱头。对于精简XML配置文件来说，它是一个好办法，但它实际上增加了复杂性，尤其是在运行包含大量类声明的项目时。虽然Spring允许混合使用自动绑定和显式绑定，但这会使XML配置更加晦涩难懂。

2.使用命名约定
该原则对于Java编码也一样适用。在项目中使用清晰的、描述性的、一致的命名约定将非常有利于开发人员理解XML配置。例如，对于bean ID，可以按照Java类字段名约定来命名它。OrderServiceDAO实例的bean ID应该命名为orderServiceDAO。对于大型项目，可以在bean ID前面加上包名作为前缀。

3. 使用简洁形式
简洁形式避免了冗长，因为它将属性值和引用从子元素中移入属性中。例如下面的例子：
    <bean id="orderService"
        class="com.lizjason.spring.OrderService">
        <property name="companyName">
            <value>lizjason</value>
        </property>
        <constructor-arg>
            <ref bean="orderDAO">
        </constructor-arg>
    </bean>
可以使用简洁形式将上述代码重写为：
    <bean id="orderService"
        class="com.lizjason.spring.OrderService">
        <property name="companyName"
            value="lizjason"/>
        <constructor-arg ref="orderDAO"/>
    </bean>

简洁形式自1.2版本起就可以使用。注意，对于<ref local="...">，没有简洁形式。
简洁形式不但可以节约键入工作量，而且可以使XML配置文件更清晰。当一个配置文件中定义了大量的类时，它可以显著提高可读性。

4. 对于构造函数参数匹配，类型比下标好
当构造函数含有一个以上同种类型的参数，或者属性值的标签已经被占用时，Spring允许使用从0开始的下标来避免混淆。例如：
    <bean id="billingService"
        class="com.lizjason.spring.BillingService">
        <constructor-arg index="0" value="lizjason"/>
        <constructor-arg index="1" value="100"/>
    </bean>
利用type属性来编写会更好一些，如下：
    <bean id="billingService"
        class="com.lizjason.spring.BillingService">
        <constructor-arg type="java.lang.String"
            value="lizjason"/>
        <constructor-arg type="int" value="100"/>
    </bean>

使用index可以减少一些代码，但是与type属性相比，它更易于出错且难于阅读。只有在构造函数参数不明确的时候，才应该使用index。

5. 尽可能重用已定义的bean
Spring提供了一种类似于继承的机制来减少配置信息的复制并简化XML配置。定义一个子类，它就可以从父类那里继承配置信息，而父类实际上成为子类的一个模板。这就是大型项目中所谓的重用。只需在父类bean中设置abstract=true，然后在子bean中指定parent引用。例如：
    <bean id="abstractService" abstract="true"
        class="com.lizjason.spring.AbstractService">
        <property name="companyName"
            value="lizjason"/>
    </bean>

    <bean id="shippingService"
        parent="abstractService"
        class="com.lizjason.spring.ShippingService">
        <property name="shippedBy" value="lizjason"/>
    </bean>

ShippingService类从abstractService类继承companyName属性的值——lizjason。如果一个bean没有指定类或工厂方法，那么这个bean便是抽象的。

6. 在导入时，首选通过ApplicationContext来汇编bean定义
像Ant脚本中的导入一样，Spring的import元素对于汇编模块化的bean定义来说是很有用的。例如：
    <beans>
        <import resource="billingServices.xml"/>
        <import resource="shippingServices.xml"/>
        <bean id="orderService"
            class="com.lizjason.spring.OrderService"/>
    <beans>

然而，相对于使用import在XML配置中进行预汇编，通过ApplicationContext来配置这些bean则显得更加灵活。使用ApplicationContext的话，XML配置也更易于管理。可以向ApplictionContext构造函数传递一组bean定义，如下：
    String[] serviceResources =
        {"orderServices.xml",
        "billingServices.xml",
        "shippingServices.xml"};
    ApplicationContext orderServiceContext = new
        ClassPathXmlApplicationContext(serviceResources);

7. 使用id作为bean标识符
可以指定一个id或名称来作为bean标识符。虽然使用id不能提高可读性，但是它可以利用XML分析程序来对bean引用进行验证。如果由于XML IDREF的约束而不能使用某个id，那么可以使用名称来作为bean的标识符。XML IDREF的约束是：id必须以字母（或者XML规范中定义的标点符号）开头，后面是字母、数字、连字符、下划线、冒号或句点。实际上，很少会遇到XML IDREF约束问题。

8. 在开发阶段使用依赖性检查（dependency-check）
可以在bean定义中为dependency-check属性设置一个非默认值，比如simple、objects或all，以便容器进行依赖性检查。当需要显式或通过自动绑定设置bean的全部属性（或某类属性）时，依赖性检查便显得很有用。
    <bean id="orderService"
        class="com.lizjason.spring.OrderService"
        dependency-check="objects">
        <property name="companyName"
            value="lizjason"/>
        <constructor-arg ref="orderDAO"/>
    </bean>

在这个例子中，容器确保为orderService bean设置的属性不是primitives或collections。也可以为所有的bean设置默认依赖性检查，但是我们很少这样做，因为有些bean属性根本就不必设置。

9. 为每个配置文件添加首部注释
最好使用描述性的id和名称来取代XML配置文件中的内置注释。此外，添加一个配置文件首部也很有用，它可以概述文件中所定义的bean。可以选择将描述添加到description标签中。例如：
    <beans>
        <description>
            This file defines billing service
            related beans and it depends on
            baseServices.xml,which provides
            service bean templates...
        </description>
        ...
    </beans>
使用description标签的一个好处是可以轻松地利用工具从标签中选获取描述内容。

10. 对于更改，团队成员要积极交流
在重构Java代码时，需要随时更新配置文件并通知团队成员。XML配置文件也是代码，它们是应用程序的至关重要的部分，但是它们难于阅读和维护。大部分情况下，需要同时阅读XML配置文件和运行中的Java代码。

11. Setter注入优于构造函数注入
Spring提供了3种类型的依赖注入：构造函数注入（constructor injection）、setter注入（setter injection）和方法注入（method injection）。我们一般只用前两种。
    <bean id="orderService"
        class="com.lizjason.spring.OrderService">
        <constructor-arg ref="orderDAO"/>
    </bean>

    <bean id="billingService"
        class="com.lizjason.spring.BillingService">
        <property name="billingDAO"
            ref="billingDAO">
    </bean>

在这个例子中，orderService类使用的是构造函数注入，而BillingService类使用的是setter注入。构造函数注入可以确保bean不会在一个非法状态下被创建，但是setter注入更加灵活且更易于管理，尤其是在类包含许多属性并且其中一些可选的情况下。

12. 不要滥用依赖注入
最后一点，Spring ApplicationContext可以为您创建Java对象，但并不是所有的Java对象都应通过依赖注入来创建。例如，全局对象不应该通过ApplicationContext来创建。Spring是一个很棒的框架，但是，就可读性和易管理性而言，如果定义了大量bean，基于XML的配置就可能成为问题。过度使用依赖注入会使XML配置变得复杂且臃肿。要知道，借助于功能强大的IDE（如Eclipse和IntelliJ），Java代码比XML文件更加易读、易维护、易管理。

结束语
XML是通用的Spring配置方式。但如果定义了大量bean，基于XML的配置就会变得冗长而不实用。Spring提供了丰富的配置选项，恰当地利用其中的选项可以使XML配置更清晰，但是，有些选项（如autowiring）往往会降低配置文件的可读性和可维护性。遵循本文中所描述的最佳实践，将有助于您创建出清晰易读的XML配置文件。