Ioc知识整理(一):
IoC (Inversion of Control) 控制反转。
1.bean的别名
我们每个bean元素都有一个id属性,用于唯一标识实例化的一个类,其实name属性也可用来标识一个类,我们还可以通过</alias>元素来给一个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的<list/>
、<map/>
、<set/>
或<props/>
元素,子集合的值从其父集合继承和覆盖而来;也就是说,父子集合元素合并后的值就是子集合中的最终结果,而且子集合中的元素值将覆盖父集全中对应的值:
<bean id="parent" class="com.xiaoluo.spring2.Parent" abstract="true">
<property name="parentProperties">
<props>
<prop key="administrator">administrator@gmail.com</prop>
<prop key="support">support@gmail.com</prop>
</props>
</property>
</bean> <bean id="child" parent="parent">
<property name="parentProperties">
<props merge="true">
<prop key="sales">sales@gmail.com</prop>
<prop key="support">support@qq.com</prop>
</props>
</property>
</bean>
当在child里想要使用集合合并时,merge属性设置成true,则当child
bean被容器实际解析及实例化时,其 adminEmails
将与父集合的adminEmails
属性进行合并。注意到这里子bean的Properties
集合将从父<props/>
继承所有属性元素。同时子bean的support
值将覆盖父集合的相应值。结果如下:
{support=support@qq.com, administrator=administrator@gmail.com, sales=sales@gmail.com}
如果不设置merge="true",则child bean在被容器实例化时,就不会合并父集合的属性,而只会得到自己集合的内容,结果如下:
{support=support@qq.com, sales=sales@gmail.com}
3.自动装配模式(autowire mode):
直接上spring官方文档截图:
当然自动装配也存在着一下优缺点,大家可以根据实际需要选择是否使用自动装配:
优点:
自动装配能显著减少配置的数量。不过,采用bean模板也可以达到同样的目的。
自动装配可以使配置与java代码同步更新。例如,如果你需要给一个java类增加一个依赖,那么该依赖将被自动实现而不需要修改配置。因此强烈推荐在开发过程中采用自动装配,而在系统趋于稳定的时候改为显式装配的方式。
缺点:
尽管自动装配比显式装配更神奇,但是,正如上面所提到的,Spring会尽量避免在装配不明确的时候进行猜测,因为装配不明确可能出现难以预料的结果,而且Spring所管理的对象之间的关联关系也不再能清晰的进行文档化。
对于那些根据Spring配置文件生成文档的工具来说,自动装配将会使这些工具没法生成依赖信息。
如果在自动装配时想将某个bean排除在自动装配之外,只需要将该bean的autowire-candidate属性设置成false即可,这样在自动装配时会忽略掉该bean。
4.依赖检查
模式 说明
none 没有依赖检查,如果bean的属性没有值得话可以不设置
simple 对于原始类型及集合(除协作者外的一切东西)执行依赖检查
object 仅对协作者执行依赖检查
all 对协作者,原始类型及集合执行依赖检查
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)
}
}