IoC，中文名又叫控制反转，顾名思义：控制权反转，原来的要求方变成被要求方。
其作用是规范流程中的行为，是一种灵活性对性能的妥协。
这个概念在Spring中的使用为人所熟知，做Java的人都耳熟能详，就不赘述了。
那么，IoC在企业中的表现是什么呢？
我们以一个例子开始：
在中国的餐馆，吃饭的时候你只需要坐下，有服务员给你找座位，有服务员给你来点餐，有服务员给你送上来，吃完有服务器给你收拾桌子。
你要做的就是：进去，点菜，吃，掏钱，走人。
在麦当劳，就是一个控制反转的例子，我们不是服务方，而是提供方，你要吃饭，要按照我们制定的规范来。
你要做的就是：进去，排队，点餐，站等，掏钱，拿餐，找座位，吃饭，收拾桌子，餐盘带到垃圾桶，走人。
很明显，很多服务员干的工作由我们来干了。
麦当劳节约了服务成本，而你付出了服务成本，至于他节约的服务成本会不会转化成饭的价格降低，鬼才知道。
回归到软件行业，大家经常说的需求方就是一个例子：
普通的项目是这样做的：
A需求方提出：网站部给我做几个这样的页面，能够给公司赚钱，于是网站部按照A需求方的要求做项目。
花了3天。
B需求方提出：网站部给我做几个这样的页面，能够给公司赚钱，于是网站部按照B需求方的要求做项目。
花了3天。
需求方满意了，网站部苦逼了，公司赚了钱。
控制反转的情况：
网站部规定，我们每天接受奇怪的需求很累，所以需求方给我提需求，必须按照我现有的资源库来提，这样我才能简单的就把东西做出来。
不准提我没有的资源，不然卡你3天的需求。才来一个月不知道我有什么资源？那是你的问题，那个干了8年的需求方知道，所以你也必须知道。
这样的后果：网站部快速的完成了所有的需求，年终考评100分。但是需求方做出来的东西都是2B+傻逼，年终得了0分，被领导喷了。公司过几天倒闭了。
万幸的是：我们是苦逼的程序员，为了公司好，再奇葩的要求我们都接受。
再回归到我们是需求方，而运维和DBA是项目组的情况。
普通的项目是这样的：
我们开发的东西，告知运维上线，DBA调整数据库，一切为了完成需求方的需求，最终上线为公司赚钱。
控制反转的情况：
运维和DBA规定：我们每天接受奇怪的需求很累，所以你们要上线，必须按照我现有的资源库来提，按照我要的格式给我，这样我才能简单的就把东西做出来。
不准提我没有的资源，不然别指望我给你做，做了也得喷你一顿。才来一个月不知道我有什么资源？那是你的问题，那个干了8年的开发知道，所以你也必须知道。
这样的后果：一边接受着需求方随时会变的需求，一边改了之后还得忍着运维和DBA反复的鄙视和喷去求着上线，做出来的东西又慢又差。
正确的做法：转变服务意识，吸收低级运维和dba，进行基础日常运维工作，高级人员负责指导，嫌累的滚蛋。
操蛋的现实：公司不敢招新手DBA，高级的又太贵，所以还是压榨便宜的程序员吧。
最终的结果：反正也改变不了，不如骗骗自己和主管：没啥影响，这是为了公司好。