Spring学习篇：IoC知识整理(一)

现在正通过spring的官方文档学习spring，将自己学习时的点点滴滴记录下来。

Ioc知识整理(一)：

IoC (Inversion of Control) 控制反转。

1.bean的别名

我们每个bean元素都有一个id属性，用于唯一标识实例化的一个类，其实name属性也可用来标识一个类，我们还可以通过元素来给一个bean起一个别名：

    <bean name="doSpring" class="com.xiaoluo.spring.DoSpring">
    bean>    
    
    <alias name="doSpring" alias="do"/>

前提是已经实例化了一个bean，name属性="doSpring"，这样在getBean时不但可以用doSpring，也可以用do来代替。

2.集合的合并

从Spring 2.0开始，就可以使用集合的合并，我们可以定义parent-style和child-style的、、或元素，子集合的值从其父集合继承和覆盖而来；也就是说，父子集合元素合并后的值就是子集合中的最终结果，而且子集合中的元素值将覆盖父集全中对应的值：

    <bean id="parent" class="com.xiaoluo.spring2.Parent" abstract="true">
        <property name="parentProperties">
            <props>
                <prop key="administrator">[email protected]prop>
                <prop key="support">[email protected]prop>
            props>
        property>
    bean>    
    
    <bean id="child" parent="parent">
        <property name="parentProperties">
            <props merge="true">
                <prop key="sales">[email protected]prop>
                <prop key="support">[email protected]prop>
            props>
        property>
    bean>        

当在child里想要使用集合合并时，merge属性设置成true，则当child bean被容器实际解析及实例化时，其 adminEmails将与父集合的adminEmails属性进行合并。注意到这里子bean的Properties集合将从父继承所有属性元素。同时子bean的support值将覆盖父集合的相应值。结果如下：

{[email protected], [email protected], [email protected]}

如果不设置merge="true"，则child bean在被容器实例化时，就不会合并父集合的属性，而只会得到自己集合的内容，结果如下:

{[email protected], [email protected]}

3.自动装配模式(autowire mode):

直接上spring官方文档截图：

当然自动装配也存在着一下优缺点，大家可以根据实际需要选择是否使用自动装配：

优点：

• 自动装配能显著减少配置的数量。不过，采用bean模板也可以达到同样的目的。

• 自动装配可以使配置与java代码同步更新。例如，如果你需要给一个java类增加一个依赖，那么该依赖将被自动实现而不需要修改配置。因此强烈推荐在开发过程中采用自动装配，而在系统趋于稳定的时候改为显式装配的方式。

缺点:

• 尽管自动装配比显式装配更神奇，但是，正如上面所提到的，Spring会尽量避免在装配不明确的时候进行猜测，因为装配不明确可能出现难以预料的结果，而且Spring所管理的对象之间的关联关系也不再能清晰的进行文档化。

• 对于那些根据Spring配置文件生成文档的工具来说，自动装配将会使这些工具没法生成依赖信息。

如果在自动装配时想将某个bean排除在自动装配之外，只需要将该bean的autowire-candidate属性设置成false即可，这样在自动装配时会忽略掉该bean。

4.依赖检查：

5.bean作用域：

singleton：顾名思义，类似于单例模式，但是请注意：Spring的singleton bean概念与“四人帮”（GoF）模式一书中定义的Singleton模式是完全不同的。经典的GoF Singleton模式中所谓的对象范围是指在每一个ClassLoader中指定class创建的实例有且仅有一个。把Spring的singleton作用域描述成一个container对应一个bean实例最为贴切。对于无状态的类(只包含方法而没有成员变量)，为其生成bean时通常将其scope定义为singleton，singleton是bean作用域的缺省作用域，这样多个对象在引用时都共享这一份对象。

<bean id="personServiceTarget" class="com.xiaoluo.service.impl.PersonServiceImpl" scope="singleton" />

prototype：Prototype作用域的bean会导致在每次对该bean请求（将其注入到另一个bean中，或者以程序的方式调用容器的getBean()方法）时都会创建一个新的bean实例。根据经验，对有状态的bean应该使用prototype作用域，而对无状态的bean则应该使用singleton作用域。

<bean id="savePersonAction" class="com.xiaoluo.action.person.SavePersonAction" scope="prototype" />

注意：在web应用中，对于action或者servlet的bean，其bean作用域一定要定义成prototype或者是request(spring3我将bean定义成request不成功不知道为什么，所以建议统一定义成prototype)！

request：针对每次HTTP请求，Spring容器会根据loginAction bean定义创建一个全新的LoginAction bean实例， 且该loginAction bean实例仅在当前HTTP request内有效，因此可以根据需要放心的更改所建实例的内部状态， 而其他请求中根据loginAction bean定义创建的实例，将不会看到这些特定于某个请求的状态变化。 当处理请求结束，request作用域的bean实例将被销毁。

<bean id="loginAction" class="com.xiaoluo.action.LoginAction" scope="request" />

6.bean生命周期：

Spring提供了几个标志接口（marker interface），这些接口用来改变容器中bean的行为；它们包括InitializingBean和DisposableBean。实现这两个接口的bean在初始化和析构时容器会调用前者的afterPropertiesSet()方法，以及后者的destroy()方法。

1）初始化回调：

实现org.springframework.beans.factory.InitializingBean接口允许容器在设置好bean的所有必要属性后，执行初始化事宜。InitializingBean接口仅指定了一个方法：

void afterPropertiesSet() throws Exception;

通常，要避免使用InitializingBean接口并且不鼓励使用该接口，因为这样会将代码和Spring耦合起来，有一个可选的方案是，可以在Bean定义中指定一个普通的初始化方法，然后在XML配置文件中通过指定init-method属性来完成。如下面的定义所示：

<bean id="exampleInitBean" class="examples.ExampleBean" init-method="init" />

public class ExampleBean {
    
    public void init() {
        // do some initialization work
    }
}

效果和下面一模一样：

<bean id="exampleInitBean" class="examples.AnotherExampleBean" />

public class AnotherExampleBean implements InitializingBean {
    
    public void afterPropertiesSet() {
        // do some initialization work
    }
}

这里建议使用第一种方式，这样不会将代码和Spring耦合在一起。

2）折构回调：

如同初始化回调，折构回调也定义了一个标志接口，实现org.springframework.beans.factory.DisposableBean接口的bean允许在容器销毁该bean的时候获得一次回调。DisposableBean接口也只规定了一个方法：

void destroy() throws Exception;

通常，要避免使用DisposableBean标志接口而且不鼓励使用该接口，因为这样会将代码与Spring耦合在一起，有一个可选的方案是，在bean定义中指定一个普通的析构方法，然后在XML配置文件中通过指定destroy-method属性来完成。如下面的定义所示：

<bean id="exampleInitBean" class="examples.ExampleBean" destroy-method="cleanup" />

public class ExampleBean {

    public void cleanup() {
        // do some destruction work (like releasing pooled connections)
    }
}

效果和下面代码一样：

<bean id="exampleInitBean" class="examples.AnotherExampleBean" />

public class AnotherExampleBean implements DisposableBean {

    public void destroy() {
        // do some destruction work (like releasing pooled connections)
    }
}

这样也不会将代码和Spring耦合在一起。