简要描述spring IOC的基本原理,spring ioc工作原理

  简要描述spring IOC的基本原理,spring ioc工作原理

  00-1010 1 IOC的理论背景2什么是控制反转(IOC)3 IOC的别名:依赖注入(DI) 4有什么好处DI)4 IOC带给我们的5 IOC容器的技术分析6 IOC容器的一些产品7使用IOC框架需要注意什么?

  00-1010众所周知,在用面向对象方法设计的软件系统中,它的底层实现是由N个对象组成的,各个对象相互配合,最终实现系统的业务逻辑。

  如果我们打开机械表的后盖,会看到类似上面的情况。每个齿轮驱动时针、分针和秒针顺时针旋转,从而在表盘上产生正确的时间。

  该图描述了这样一个齿轮组,该齿轮组具有多个独立的齿轮,这些齿轮相互啮合,共同完成某项任务。我们可以看到,在这样的齿轮组中,如果一个齿轮出了问题,就可能影响整个齿轮组的正常运转。

  齿轮组中齿轮之间的啮合关系非常类似于软件系统中对象之间的耦合关系。对象之间的耦合关系是必然的、必要的,这是协同工作的基础。现在,随着工业应用的规模越来越大,对象之间的依赖关系也越来越复杂,经常会出现对象之间的多重依赖关系。因此,架构师和设计师在系统分析和设计中将面临更大的挑战。

  对象之间耦合度过高的系统,必然会出现牵一发而动全身的情形.

  耦合不仅会发生在对象之间,还会发生在软件系统的模块之间以及软件系统和硬件系统之间。如何降低系统、模块和对象之间的耦合度是软件工程永恒的目标之一。

  为了解决对象之间耦合度过高的问题,软件专家Michael Mattson提出了IOC理论来实现对象之间的解耦。目前,这一理论已经成功应用于实践,许多J2EE项目都采用了IOC框架产品Spring。

  

目录

IOC是控制反转的缩写。大部分书翻译为“控制反转”,也有一些书翻译为“控制反转”或“控制反转”。

 

  1996年,Michael Mattson在一篇关于面向对象框架的文章中首次提出了IOC的概念。

  简单来说,就是把复杂的系统分解成协作的对象。这些对象类封装后,内部实现对外透明,降低了问题求解的复杂度,可以灵活复用和扩展。

  IOC理论提出的观点大致如下:有依赖关系的对象之间的解耦是借助“第三方”实现的,

  如下图:

  由于中间引入了“第三方”,即IOC容器,A、B、C、D四个对象没有耦合关系,齿轮之间的传递全部依赖于“第三方”,所有对象的控制权都交给了“第三方”IOC容器。因此,IOC容器成为整个系统的关键核心,它充当了一种“粘合剂”,使系统

  我们再来做个试验:把上图中间的IOC容器拿掉,然后再来看看这套系统:

  我们现在看到的是实现整个系统所需要完成的全部工作。此时,A、B、C、D四个对象没有耦合关系,彼此无关。这样,你在实现A的时候,根本不需要考虑B、C、D,对象之间的依赖已经降到了最低。所以,如果IOC容器真的能够实现,对于系统开发来说,将是一件非常美妙的事情。每个参与开发的成员只需要实现自己的类就可以了,与他人无关!

  在软件引入IOC容器之前,如图1所示,对象A依赖于对象B,所以当对象A初始化或者运行到某一点时,它必须主动创建对象B或者使用已经创建好的对象B,不管你是创建还是使用对象B,控制权都在自己手里。在软件系统中引入IOC容器后,这种情况彻底改变了。如图3所示,由于添加了IOC容器,对象A和对象B之间的直接连接已经丢失。所以当对象A运行到需要对象B的地方,IOC容器会主动创建一个对象B,注入到对象A需要的地方。

  通过前后对比,我们可以看到,A对象获得依赖对象B的过程,从主动行为变成了被动行为和控制。

  权颠倒过来了,这就是控制反转这个名称的由来

  

 

  

3 IOC的别名:依赖注入(DI)

2004年,Martin Fowler探讨了同一个问题,既然IOC是控制反转,那么到底是哪些方面的控制被反转了呢?经过详细地分析和论证后,他得出了答案:获得依赖对象的过程被反转了。控制被反转之后,获得依赖对象的过程由自身管理变为了由IOC容器主动注入。于是,他给控制反转取了一个更合适的名字叫做依赖注入(Dependency Injection)。他的这个答案,实际上给出了实现IOC的方法:注入。

 

  

所谓依赖注入,就是由IOC容器在运行期间,动态地将某种依赖关系注入到对象之中。

 

  

所以,依赖注入(DI)和控制反转(IOC)是从不同的角度的描述的同一件事情,就是指通过引入IOC容器,利用依赖关系注入的方式,实现对象之间的解耦

 

  我们举一个生活中的例子,来帮助理解依赖注入的过程。大家对USB接口和USB设备应该都很熟悉吧,USB为我们使用电脑提供了很大的方便,现在有很多的外部设备都支持USB接口。

  

 

  现在,我们利用电脑主机和USB接口来实现一个任务:从外部USB设备读取一个文件。电脑主机读取文件的时候,它一点也不会关心USB接口上连接的是什么外部设备,而且它确实也无须知道。它的任务就是读取USB接口,挂接的外部设备只要符合USB接口标准即可。

  所以,如果我给电脑主机连接上一个U盘,那么主机就从U盘上读取文件;如果我给电脑主机连接上一个外置硬盘,那么电脑主机就从外置硬盘上读取文件。

  挂接外部设备的权力由我作主,即控制权归我,至于USB接口挂接的是什么设备,电脑主机是决定不了,它只能被动的接受。电脑主机需要外部设备的时候,根本不用它告诉我,我就会主动帮它挂上它想要的外部设备,你看我的服务是多么的到位。这就是我们生活中常见的一个依赖注入的例子。在这个过程中,我就起到了IOC容器的作用。

  通过这个例子,依赖注入的思路已经非常清楚:当电脑主机读取文件的时候,我就把它所要依赖的外部设备,帮他挂接上。整个外部设备注入的过程和一个被依赖的对象在系统运行时被注入另外一个对象内部的过程完全一样。我们把依赖注入应用到软件系统中,再来描述一下这个过程:

  对象A依赖于对象B,当对象 A需要用到对象B的时候,IOC容器就会立即创建一个对象B送给对象A。IOC容器就是一个对象制造工厂,你需要什么,它会给你送去,你直接使用就行了,而再也不用去关心你所用的东西是如何制成的,也不用关心最后是怎么被销毁的,这一切全部由IOC容器包办。在传统的实现中,由程序内部代码来控制组件之间的关系。我们经常使用new关键字来实现两个组件之间关系的组合,这种实现方式会造成组件之间耦合。IOC很好地解决了该问题,它将实现组件间关系从程序内部提到外部容器,也就是说由容器在运行期将组件间的某种依赖关系动态注入组件中。

  

 

  

4 IOC为我们带来了什么好处

我们还是从USB的例子说起,使用USB外部设备比使用内置硬盘,到底带来什么好处?

 

  第一、USB设备作为电脑主机的外部设备,在插入主机之前,与电脑主机没有任何的关系,只有被我们连接在一起之后,两者才发生联系,具有相关性。所以,无论两者中的任何一方出现什么的问题,都不会影响另一方的运行。这种特性体现在软件工程中,就是可维护性比较好,非常便于进行单元测试,便于调试程序和诊断故障。代码中的每一个Class都可以单独测试,彼此之间互不影响,只要保证自身的功能无误即可,这就是组件之间低耦合或者无耦合带来的好处。第二、USB设备和电脑主机的之间无关性,还带来了另外一个好处,生产USB设备的厂商和生产电脑主机的厂商完全可以是互不相干的人,各干各事,他们之间唯一需要遵守的就是USB接口标准。这种特性体现在软件开发过程中,好处可是太大了。每个开发团队的成员都只需要关心实现自身的业务逻辑,完全不用去关心其它的人工作进展,因为你的任务跟别人没有任何关系,你的任务可以单独测试,你的任务也不用依赖于别人的组件,再也不用扯不清责任了。所以,在一个大中型项目中,团队成员分工明确、责任明晰,很容易将一个大的任务划分为细小的任务,开发效率和产品质量必将得到大幅度的提高。第三、同一个USB外部设备可以插接到任何支持USB的设备,可以插接到电脑主机,也可以插接到DV机,USB外部设备可以被反复利用。在软件工程中,这种特性就是可复用性好,我们可以把具有普遍性的常用组件独立出来,反复利用到项目中的其它部分,或者是其它项目,当然这也是面向对象的基本特征。显然,IOC不仅更好地贯彻了这个原则,提高了模块的可复用性。符合接口标准的实现,都可以插接到支持此标准的模块中。第四、同USB外部设备一样,模块具有热插拔特性。IOC生成对象的方式转为外置方式,也就是把对象生成放在配置文件里进行定义,这样,当我们更换一个实现子类将会变得很简单,只要修改配置文件就可以了,完全具有热插拨的特性。以上几点好处,难道还不足以打动我们,让我们在项目开发过程中使用IOC框架吗?

  

 

  

5 IOC容器的技术剖析

IOC中最基本的技术就是反射(Reflection)编程,目前.Net C#、Java和PHP5等语言均支持,其中PHP5的技术书籍中,有时候也被翻译成映射。有关反射的概念和用法,大家应该都很清楚,通俗来讲就是根据给出的类名(字符串方式)来动态地生成对象。

 

  这种编程方式可以让对象在生成时才决定到底是哪一种对象。反射的应用是很广泛的,很多的成熟的框架,比如象Java中的Hibernate、Spring框架,.Net中 NHibernate、Spring.Net框架都是把反射做为最基本的技术手段。反射技术其实很早就出现了,但一直被忽略,没有被进一步的利用。当时的反射编程方式相对于正常的对象生成方式要慢至少得10倍。现在的反射技术经过改良优化,已经非常成熟,反射方式生成对象和通常对象生成方式,速度已经相差不大了,大约为1-2倍的差距。

  我们可以把IOC容器的工作模式看做是工厂模式的升华,可以把IOC容器看作是一个工厂,这个工厂里要生产的对象都在配置文件中给出定义,然后利用编程语言的的反射编程,根据配置文件中给出的类名生成相应的对象。从实现来看,IOC是把以前在工厂方法里写死的对象生成代码,改变为由配置文件来定义,也就是把工厂和对象生成这两者独立分隔开来,目的就是提高灵活性和可维护性。

  

 

  

6 IOC容器的一些产品

Sun ONE技术体系下的IOC容器有:

 

    轻量级的有Spring、Guice、Pico Container、Avalon、HiveMind;  重量级的有EJB;  不轻不重的有JBoss,Jdon等等。Spring框架作为Java开发中最流行的框架之一,大中小项目中都有使用,非常成熟,应用广泛,EJB在关键性的工业级项目中也被使用,比如某些电信业务。.Net技术体系下的IOC容器有:Spring.Net、Castle等等。Spring.Net是从Java的Spring移植过来的IOC容器,Castle的IOC容器就是Windsor部分。它们均是轻量级的框架,比较成熟,其中Spring.Net已经被逐渐应用于各种项目中。

  

 

  

7 使用IOC框架应该注意什么

使用IOC框架产品能够给我们的开发过程带来很大的好处,但是也要充分认识引入IOC框架的缺点,做到心中有数,杜绝滥用框架。

 

  第一、软件系统中由于引入了第三方IOC容器,生成对象的步骤变得有些复杂,本来是两者之间的事情,又凭空多出一道手续,所以,我们在刚开始使用IOC框架的时候,会感觉系统变得不太直观。所以,引入了一个全新的框架,就会增加团队成员学习和认识的培训成本,并且在以后的运行维护中,还得让新加入者具备同样的知识体系。第二、由于IOC容器生成对象是通过反射方式,在运行效率上有一定的损耗。如果你要追求运行效率的话,就必须对此进行权衡。第三、具体到IOC框架产品(比如:Spring)来讲,需要进行大量的配制工作,比较繁琐,对于一些小的项目而言,客观上也可能加大一些工作成本。第四、IOC框架产品本身的成熟度需要进行评估,如果引入一个不成熟的IOC框架产品,那么会影响到整个项目,所以这也是一个隐性的风险。到此这篇关于Spring的IOC原理详情的文章就介绍到这了,更多相关Spring IOC 内容请搜索盛行IT以前的文章或继续浏览下面的相关文章希望大家以后多多支持盛行IT!

郑重声明:本文由网友发布,不代表盛行IT的观点,版权归原作者所有,仅为传播更多信息之目的,如有侵权请联系,我们将第一时间修改或删除,多谢。

相关文章阅读

  • spring编程式事务处理,spring编程事务
  • spring编程式事务处理,spring编程事务,详解Spring学习之编程式事务管理
  • spring的核心功能模块有几个,列举一些重要的spring模块
  • spring的核心功能模块有几个,列举一些重要的spring模块,七个Spring核心模块详解
  • spring注解和springmvc的注解,SpringMVC常用注解
  • spring注解和springmvc的注解,SpringMVC常用注解,详解springmvc常用5种注解
  • spring实现ioc的四种方法,spring的ioc的三种实现方式
  • spring实现ioc的四种方法,spring的ioc的三种实现方式,简单实现Spring的IOC原理详解
  • spring事务失效问题分析及解决方案怎么做,spring 事务失效情况
  • spring事务失效问题分析及解决方案怎么做,spring 事务失效情况,Spring事务失效问题分析及解决方案
  • spring5.0新特性,spring4新特性
  • spring5.0新特性,spring4新特性,spring5新特性全面介绍
  • spring ioc以及aop原理,springmvc aop原理
  • spring ioc以及aop原理,springmvc aop原理,深入浅析Spring 的aop实现原理
  • Spring cloud网关,spring cloud zuul作用
  • 留言与评论(共有 条评论)
       
    验证码: