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值将覆盖父集合的相应值。结果如下:

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

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

直接上spring官方文档截图:

Spring学习篇:IoC知识整理(一)_第1张图片

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

优点:

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

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

缺点:

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

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

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

4.依赖检查:

5.bean作用域:

Spring学习篇:IoC知识整理(一)_第2张图片

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的行为;它们包括InitializingBeanDisposableBean。实现这两个接口的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耦合在一起。

 

 

你可能感兴趣的:(Spring学习篇:IoC知识整理(一))