IOC 初谈

IOC是什么?

Ioc 大致有两个名字：依赖注入、控制反转， 究竟哪个更合适一点，我们通过一个例子来看一下。

没有引入Ioc容器之前，对象A依赖对象B，那么对象A初始化或运行的时候需要依赖B，那么必须主动去创建对象B和使用已创建好的对象B，无论是创建还是使用对象B，控制权都在A手里。

使用Ioc容器后呢？？？ Ioc容器加入后，对象A和对象B之间没有了直接联系，B的创建使用控制权不在A手里，在哪儿呢？在Ioc容器中，当A对象要创建、使用对象B的时候，Ioc容器会主动创建一个对象B注入到对象A需要的地方。如下图

                                               

通过对比我们可以看出来，对象A获取对象B的过程，由主动行为变成了被动行为，控制权颠倒了，所以也有很多人叫他控制反转，

你们觉得那个名字合适？ 

好像有点多此一问哈，通过这个问题，希望各位小伙伴对Ioc有更深一点的理解，小编在此装了一把13，不服来打我啊。?

 

IOC的优缺点

世界上没有完美的技术，只有合适的场景，希望不要滥用，正如没有完美的男友（女友），只有最适合你的那一位，且行且珍惜。

第一、软件系统中由于引入了第三方Ioc容器，生成对象的过程变得有点复杂，本来A使用B就直接干了，结果多了一道手续，（怎么感觉像是A搞B，结果多了一个套套，我擦，我污了），所以刚开或者没接触过Ioc框架时，会感觉系统不太直观，甚至小新会感觉什么垃圾项目（曾经我也有过这种想法），所以Ioc框架的引入肯定会增加团队成员的学习成本，不过我TM那管这些，我用的就是高大上的技术，不会的都是小渣渣。 （摆出傲视群雄的态度）

第二、由于Ioc容器生成对象是通过反射的方式，在运行效率上有一定损耗，如果追求运行效率，对此有个清楚认识。

第三、Ioc框架，需要大量的配置工作，比较繁琐，对小项目来说有点加大成本了。（什么叫小项目？你猜哈哈）

第四、Ioc框架本身成熟度需要评估，不成熟的Ioc框架会影响整个项目，是一个稳定性的风险，（.net 我推荐Spring.net，Java推荐Spring，这疗效谁用谁知道）

结论：一些工作量不大的项目或者产品，不太适合使用IOC框架产品。另外，如果团队成员的知识能力欠缺，对于IOC框架产品缺乏深入的理解，也不要贸然引入。最后，特别强调运行效率的项目或者产品，也不太适合引入IOC框架产品，像WEB2.0网站就是这种情况。

 

IOC容器的技术剖析

IOC中最基本的技术就是“反射”

IOC容器一些产品

Sun ONE技术体系下的IOC容器有：轻量级的有Spring、Guice、Pico Container、Avalon、HiveMind；重量级的有EJB；不轻不重的有JBoss，Jdon等等。Spring框架作为Java开发中SSH(Struts、Spring、Hibernate)三剑客之一，大中小项目中都有使用，非常成熟，应用广泛，EJB在关键性的工业级项目中也被使用，比如某些电信业务。

    .Net技术体系下的IOC容器有：Spring.Net、Castle等等。Spring.Net是从Java的Spring移植过来的IOC容器，Castle的IOC容器就是Windsor部分。它们均是轻量级的框架，比较成熟，其中Spring.Net已经被广泛应用于各种项目中。

 

参考博文：https://www.cnblogs.com/DebugLZQ/archive/2013/06/05/3107957.html