Spring IoC控制反转总结

Spring IoC控制反转总结
[code]

IoC（Inversion of Control）经常称为控制反转或是依赖注入（Dependence Injection）。通俗的讲就是若需要在具体的应用程序中需要创建一个对象的话，我们不用自己去通new方法生成需要的对象，而是通过spring程序包提供的bean工厂为我们生产这样的一个对象。
在IoC模式下，应用程序不负责创建对象，但是需要描述创建它们的方式。采用IoC在具体的程序代码中不直接与对象和服务连接，但需要在配置文件中描述哪一个组件需要哪一项服务，由容器负责将这些联系在一起。
关于spring之IoC常见问题点的分析总结：
1、工厂方法模式与IoC的实现方面差异。
IoC 采用配置文件来获取具体目标对象的实现，提高了改变要选择的目标对象的灵活性。在工厂方法模式中，会出现以硬编码方式出现目标对象的实现类（采用可配置化的工厂类可以避免硬编码，但是也会带来额外的维护负担）。Spring框架会对IoC的XML配置文件中的各个配置项目进行解析，然后利用Java的“反射”技术，根据在XML配置文件中给出的类名生成相应名称的类对象实例。另外，工厂方法在组件类的实现形式和对象实例的产生模式等方面也存在一定的缺陷。
2、是否所有的对象都交给IoC来生产。
如果需要将组件交给spring管理那就用ioc，如果不想让spring管理那可以随时new。换言之，如果组件会经常修改采用IoC比较好，改变较少用new。一般是在组件出现重用、或用到外部资源的时候，开始考虑使用IoC。
3、 IoC主要的优点缺点分析。
优点分析：因为把对象生成放在了XML里定义，所以当需要换一个实现子类将会变的比较简单（一般这样的对象都是基于某种接口实现的），只需要修改XML就可以了，这样可以实现对象的“热插拨”效果，也会方便测试及配置维护。
缺点分析：（1）生成一个对象的步骤变复杂了（基于IDE的支撑操作逐渐变得简单），不习惯该方式的话，会觉得有点别扭与不直观。（2）因为对象的创建是采用的反射机制，所以在效率上有些损耗（经SUN改良优化后，用反射方式来生成对象和一般new对象的方式，在速度方面的差异在逐步减小）。但相对于IoC提高的维护性和灵活性来说，这点损耗可以忽略不记，除非在对某对象的生成在效率方面要求特别苛刻例外。（3）在IDE进行重构操作的支持较差，如果对类进行改名等操作，还需要手动修改去XML文件之间的匹配关系，属于采用XML方式的不便之处。
Spring通过控制反转（IoC）促进了松耦合。当应用了 IoC，一个对象依靠的其它对象会通过被动的方式传送进来，而不是这个对象自己创建或者查找依靠对象。不是对象从容器中查找依靠，而是容器在对象初始化时不等对象请求就主动将依靠传送给它。阅网认为IOC更适合理解为一种设计模式。一方面可以理解为控制权的转移：由传统的在程序中控制依赖转移到由容器来控制；另外是依赖注入：将相互依赖的对象进行分离、解耦合，在Spring配置文件中描述他们之间的依赖关系，他们的依赖关系只在使用的时候才建立。

[/code]