Spring框架,个人笔记--IOC,DI,AOP
2016-10-18 10:35
381 查看
本博客很多博文都是本人日常搜索保存到word文档中,会有自己本人的理解和不少网上其他大牛的知识,有时间会慢慢整理到博客上面,因时间长无法追溯到获取来源,无法声明转载,望谅解!如有意见,可私信联系本人。此微博所有博文都只是用于个人日常笔记整理!
Spring框架,概念性东西不说,目前主流框架,网站开发有SSH,Spring+Struts2+Hibernate;SSM,Spring+SpringMVC+Mybatis
两个概念,IOC和AOP
IOC inversion of control 控制反转 ,对象创建责任的反转,一种设计思想,不在你设计好的对象交给容器控制,而不是传统的在你的对象内部直接控制,在spring中BeanFacotory是IoC容器的核心接口,负责实例化,定位,配置应用程序中的对象及建立这些对象间的依赖。XmlBeanFacotory实现BeanFactory接口,通过获取xml配置文件数据,组成应用对象及对象间的依赖关系。
有一种朋友给我解释的比较通俗的说法:比如说传统模式下:一个人口渴想喝水,得去小卖铺买水,他就得知道小卖铺怎么去,要坐什么车,有多远;然后依赖注入就是,一个人想喝水,知道小卖铺的电话,打个电话,让水直接送过来;
在我们程序中理解的话就是你在A对象中要用到B对象,传统的方式是你要知道B在哪里,然后要去找到B对象,在A中实例化B,这样你才能使用B对象
用了Spring框架,AOP和DI的概念理解就是,A中要使用到B,自动装载到容器里,有Spring容器去帮你找到这个B类,你就不需要在自己A当中再去实例化B,具体怎么找,怎么实例化就不需要你去关心了,你只管怎么用,这样就实现了分离,降低耦合度。
[b]谁控制谁,控制什么:[/b]传统Java SE程序设计,我们直接在对象内部通过new进行创建对象,是程序主动去创建依赖对象;而IoC是有专门一个容器来创建这些对象,即由Ioc容器来控制对 象的创建;谁控制谁?当然是IoC 容器控制了对象;控制什么?那就是主要控制了外部资源获取(不只是对象包括比如文件等)。
为何是反转,哪些方面反转了:有反转就有正转,传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象,也就是正转;而反转则是由容器来帮忙创建及注入依赖对象;为何是反转?因为由容器帮我们查找及注入依赖对象,对象只是被动的接受依赖对象,所以是反转;哪些方面反转了?依赖对象的获取被反转了。
同一个概念的不同角度描述:DI:Dependency Injection 依赖注入,另一个称呼是依赖倒置。原来A中要使用B,是A依赖B,现在A要使用B,依赖倒置了,所以是B依赖A
DI—Dependency Injection,即“依赖注入”:组件之间依赖关系由容器在运行期决定,形象的说,即由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能,而是为了提升组件重用的频率,并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制,我们只需要通过简单的配置,而无需任何代码就可指定目标需要的资源,完成自身的业务逻辑,而不需要关心具体的资源来自何处,由谁实现。 理解DI的关键是:“谁依赖谁,为什么需要依赖,谁注入谁,注入了什么”,那我们来深入分析一下: ●谁依赖于谁:当然是应用程序依赖于IoC容器; ●为什么需要依赖:应用程序需要IoC容器来提供对象需要的外部资源; ●谁注入谁:很明显是IoC容器注入应用程序某个对象,应用程序依赖的对象; ●注入了什么:就是注入某个对象(A)所需要的外部资源(包括对象(B)、资源、常量数据)。
AOP面向切面编程 aop就是纵向的编程,如下图所示,业务1和业务2都需要一个共同的操作,与其往每个业务中都添加同样的代码,不如写一遍代码,让两个业务共同使用这段代码。
为什么要使用Spring框架,道理是一样的,分开层次,降低耦合在不使用spring框架之前,我们的service层中要使用dao层的对象,不得不在service层中new一个对象。存在的问题就是:层与层之间的依赖。
使用框架后:service层要用dao层对象需要配置到xml配置文件中,至于对象是怎么创建的,关系是怎么组合的都交给了spring框架去实现。
Spring框架,概念性东西不说,目前主流框架,网站开发有SSH,Spring+Struts2+Hibernate;SSM,Spring+SpringMVC+Mybatis
两个概念,IOC和AOP
IOC inversion of control 控制反转 ,对象创建责任的反转,一种设计思想,不在你设计好的对象交给容器控制,而不是传统的在你的对象内部直接控制,在spring中BeanFacotory是IoC容器的核心接口,负责实例化,定位,配置应用程序中的对象及建立这些对象间的依赖。XmlBeanFacotory实现BeanFactory接口,通过获取xml配置文件数据,组成应用对象及对象间的依赖关系。
有一种朋友给我解释的比较通俗的说法:比如说传统模式下:一个人口渴想喝水,得去小卖铺买水,他就得知道小卖铺怎么去,要坐什么车,有多远;然后依赖注入就是,一个人想喝水,知道小卖铺的电话,打个电话,让水直接送过来;
在我们程序中理解的话就是你在A对象中要用到B对象,传统的方式是你要知道B在哪里,然后要去找到B对象,在A中实例化B,这样你才能使用B对象
用了Spring框架,AOP和DI的概念理解就是,A中要使用到B,自动装载到容器里,有Spring容器去帮你找到这个B类,你就不需要在自己A当中再去实例化B,具体怎么找,怎么实例化就不需要你去关心了,你只管怎么用,这样就实现了分离,降低耦合度。
[b]谁控制谁,控制什么:[/b]传统Java SE程序设计,我们直接在对象内部通过new进行创建对象,是程序主动去创建依赖对象;而IoC是有专门一个容器来创建这些对象,即由Ioc容器来控制对 象的创建;谁控制谁?当然是IoC 容器控制了对象;控制什么?那就是主要控制了外部资源获取(不只是对象包括比如文件等)。
为何是反转,哪些方面反转了:有反转就有正转,传统应用程序是由我们自己在对象中主动控制去直接获取依赖对象,也就是正转;而反转则是由容器来帮忙创建及注入依赖对象;为何是反转?因为由容器帮我们查找及注入依赖对象,对象只是被动的接受依赖对象,所以是反转;哪些方面反转了?依赖对象的获取被反转了。
同一个概念的不同角度描述:DI:Dependency Injection 依赖注入,另一个称呼是依赖倒置。原来A中要使用B,是A依赖B,现在A要使用B,依赖倒置了,所以是B依赖A
DI—Dependency Injection,即“依赖注入”:组件之间依赖关系由容器在运行期决定,形象的说,即由容器动态的将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能,而是为了提升组件重用的频率,并为系统搭建一个灵活、可扩展的平台。通过依赖注入机制,我们只需要通过简单的配置,而无需任何代码就可指定目标需要的资源,完成自身的业务逻辑,而不需要关心具体的资源来自何处,由谁实现。 理解DI的关键是:“谁依赖谁,为什么需要依赖,谁注入谁,注入了什么”,那我们来深入分析一下: ●谁依赖于谁:当然是应用程序依赖于IoC容器; ●为什么需要依赖:应用程序需要IoC容器来提供对象需要的外部资源; ●谁注入谁:很明显是IoC容器注入应用程序某个对象,应用程序依赖的对象; ●注入了什么:就是注入某个对象(A)所需要的外部资源(包括对象(B)、资源、常量数据)。
AOP面向切面编程 aop就是纵向的编程,如下图所示,业务1和业务2都需要一个共同的操作,与其往每个业务中都添加同样的代码,不如写一遍代码,让两个业务共同使用这段代码。
为什么要使用Spring框架,道理是一样的,分开层次,降低耦合在不使用spring框架之前,我们的service层中要使用dao层的对象,不得不在service层中new一个对象。存在的问题就是:层与层之间的依赖。
使用框架后:service层要用dao层对象需要配置到xml配置文件中,至于对象是怎么创建的,关系是怎么组合的都交给了spring框架去实现。
相关文章推荐
- Spring框架总结,控制反转(IOC),依赖注入(DI),面向切面编程(AOP)
- IOC(DI), AOP 笔记
- Spring特点中关于DI,IOC及AOP的个人理解
- 关于spring框架中的IOC/DI和AOP,以及声明式事务管理的理解
- OPP,OOP,AOP,IoC,DI的个人理解
- Spring特点中关于DI,IOC及AOP的个人理解
- 设计模式--IOC(DI)与AOP思想涉及的模式
- IOC/DI与AOP概念的理解(转载及修改)
- IOC/DI与AOP概念的理解(转载及修改)
- IOC、AOP学习笔记_Step1(学习资料:吕震宇的你真的了解Ioc与AOP吗?)
- Sprig 面试中 问及 DI,IOC, AOP
- 【Spring学习笔记】Spring框架的IoC容器学习笔记
- IOC/DI与AOP概念的理解
- 解释Spring中IOC, DI, AOP
- 深入浅出学习Spring框架(四):IoC和AOP的应用——事务配置
- Spring基础知识-IOC、DI、AOP
- Spring学习笔记----01. 入门知识,IoC/DI
- JAVA:Spring Ioc/AOP/DI/MVC/ 细看Springframework
- Spring学习笔记(一)----IoC之DI
- IOC DI AOP Interception