传统方式和spring方式的优缺点

      

       所谓的依赖注入就是：对象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使得面向对象的世界更加简单，面向接口编程成为了可能。