SpringIOC(1)问题软件危机遇到的重大问题:用户需求不断改变,但是每次改变意味着大量修改源代码能否在允许功能改变的情况下,尽量降低修改源代码的概率?以Struts调用Hibernate为例Struts中的Action中,execute函数调用了Dao(Hibernate)Spring思想:充分利用配置文件,来决定实例化哪个对象。类切换,只需要改配置文件即可。实例化对象的工作由Factory完成,Factory可以通用(框架化),实例化对象的工作由框架完成,对象的控制权由用户源代码转到框架中完成,这叫做控制权反转,也叫控制反转,IOC(InverseOfControl)ing作用1:控制反转将生成什么样的对象,和对象的生成过程由框架决定控制反转:IOC这是Spring的核心思想Spring作用2:依赖注入在控制反转(将生成什么样的对象,和对象的生成过程由框架决定)的基础上,在配置文件中给需要生成的对象一些简单属性方法:在需要给定属性的类中定义相应的属性,并给定get和set方法;在配置文件中的<bean>标签内,用<property>标签指定相应的属性即可类不知道有配置文件存在,但是定义了一些属性,默认值为空。系统运行时,从配置文件中获得字符串赋值给属性。形象称为“注入”,因为这个“注入”过程是框架完成的,所以叫做“依赖注入”。依赖注入思想是软件工程重要思想,为“可插拔、可组装”的软件提供了一种开发途径。基于B/S的典型三层架构问题的提出我们知道,微软公司的Windows中,可以接受各种硬件接入,如扫描仪、打印机、摄像头等。各种硬件数据传输方法不一样,有不同的驱动程序。你如果是微软公司专家,怎样对待这些驱动程序?自己编写所有可能的驱动程序,放在windows内,不好,无法预见让客户手工安装驱动程序,好,但是客户必须手工安装,比较麻烦还有没有更好的办法?Windows内发布USB接口的标准,内置了一个配置文件,规定,凡是通过USB接口接入电脑的硬件,必须实现USB接口的标准,硬件接入时,自动检测这种实现了标准的模块,修改内置的配置文件,接入成功从中我们可以学到什么?对象的生成由Spring通过读取配置文件()动态设置。测试代码仅仅面向接口编程,而无需知道实现类的具体名称。同时,我们可以很简单的通过修改配置文件来切换具体的底层实现类。(class属性)组件依赖关系减少,问题:如果用传统方法作,会有什么后果?Spring作用1:这种思想可以很好地实现同类不同质的模块切换。开发具备属性的Spring程序问题:编写一个界面(),要求:界面的标题在XML文件里面配置。传统方法:读XML文件的代码必须自己写。使用Spring可以节省这个工作(1)建立FrmTest类,增加一个title属性(2)增加spring支持(3)在配置文件中增加:<beanid=“对象名”class=“类名"><propertyname=“属性名"><value>值</value></property></bean>(4)在主函数中增加:ApplicationContextctx=newFileSystemXmlApplicationContext(“配置文件");FrmTestft=(FrmTest)(“对象名”);从中我们可以学到什么?对象的生成由Spring通过读取配置文件()动态设置。控制反转(IoC)测试代码仅仅面向接口编程,而无需知道实现类的具体名称。同时,我们可以很简单的通过修改配置文件来切换具体的底层实现类。(class属性)组件依赖关系减少,上面的例子中,我们通过Spring,在运行期动态将字符串注入到实现类的属性中。这种概念将参数传递交给容器去做,:如果用传统方法作,会有什么后果?注意:一个JavaBean一定要有一个无参数的构造函数,否则不能反射Spring作用2:可以方便地通过配置文件改变模块行为,动态注入属性值
springioc1章节 来自淘豆网www.taodocs.com转载请标明出处.