所谓的依赖注入就是:对象A依赖于对象B,当对象 A需要用到对象B的时候,IOC容器就会立即创建一个对象B送给对象A。IOC容器就是一个对象制造工厂,你需要什么,它会给你送去,你直接使用就行了,而再也不用去关心你所用的东西是如何制成的,也不用关心最后是怎么被销毁的,这一切全部由IOC容器包办。
通过IoC或DI,我们只需要通过简单的配置,而无需任何代码就可以指定UserManager中所需的UserDao的具体实现。UserManager只需利用容器注入的UserDao实例,完成自身的业务逻辑,而不用关心具体实现来自哪、由谁实现。换句话说:我们不再需要自己负责创建对象,管理对象生命周期以及维护对象的依赖关系,这些都有Spring替我们完成了。
传统方式和Spring方式对比:
传统方式:决定使用哪一个具体实现是由应用程序负责的,在编译阶段就确定了。
Spring方式:调用类只依赖接口,而不依赖具体的实现类,减少了耦合。控制权交给了容器,在运行期才由容器决定将具体的实现动态的“注入”到调用类的对象中。这也是使用IoC的根本原因。
现在我们对IoC有了基本认识,我们再理解一下IoC的概念。
IoC
IoC(Inversion of Control),控制反转,用白话来讲,就是由容器控制程序之间的关系,而非传统实现中,由程序代码直接控制。这也就是所谓“控制反转”的概念所在:控制权由应用代码中转到了外部容器,控制权的转移,就是所谓反转。
IoC的优缺点
优点:
1、把对象的创建和依赖关系定义在了XML文件中,我们改变子类的实现变得异常简单。
2、控制反转减轻了对象之间的耦合度,减轻了对象之间的依赖关系,增加了系统的灵活性,可维护性,以及可移植性等等。
缺点:
1、生成对象的方式变复杂了(事实上操作还是挺简单的),对于不习惯这种方式的人,会觉得有些别扭和不直观。
2、创建对象因为使用了反射技术,在效率上有些损耗。但相对于IoC提高的维护性和灵活性来说,这点损耗是微不足道的,除非某对象的生成对效率要求特别高。
总结
IoC使得面向对象的世界更加简单,面向接口编程成为了可能。