前言
各位牛人先别笑话我 道理虽然简单，但是愚蠢的我今天才体会了IoC的伟大，不得不分享一下。
正文
以前读书的时候就看过一个概念IoC，中文叫反向注入什么的。
当时看到这个名词，觉得特牛B，搞软件搞得和搞导弹一样，“反向”已经有点特神，“注入”又像往杯子里面注水。
后来看了原理（spring之类的），大概了解实现机制就是：用反射加载类去运行（偶知道没这么简单。。那起码是因为反射，才实现了IoC这句话没错吧）。
这么简单的东西，干嘛搞个这么复杂的名字？这个问题我一直没有想懂。叫个“反射加载”不更直接，还什么“反向”，还“注入”。。
后来。。过了几年，到了今天，我正忙着对自己的类库去重构。大概现状是这样的：
1. 我多年前开发了个持久层，namespace = Pixysoft.Framework.Noebe，有一套通用接口 INoebeManager。
2. 在接下来几年中，我基于了这个接口开发了其他的功能，例如：
A：基于web service实现持久层远程的操作, namespace = Pixysoft.Framework.Noebe.Ws
B：实现点对点同步的持久层操作, namespace = Pixysoft.Framework.Noebe.Consistency
3. 同时，在接下来几年的项目中，我开发了一些应用，如：
A：基于持久层的ORM操作，namespace = Pixysoft.Framework.Noebe.Orm
4. 现在我发现既然持久层都是基于INoebeManager这个接口，那么我在ORM里面去用不同的持久层，不就可以增加不同的功能了吗？例如：
我现在要求ORM能够支持点对点数据同步，这样我就能够实现分布式环境下的ORM操作了。
问题浮现
问题现在来了，INoebeManager这个接口在最早的开发包Pixysoft.framework.Noebe，但是其他的扩展是在后续的开发包里。
核心问题就是：底层的开发包不知道高层的类与实现。
以前的解决方法：
1. 把这个接口独立出来，成为一个新的开发包，然后日后有多少新功能，就在这个新的开发包里面去引用这些包。做个factory模式之类的，调用什么，就根据枚举之类的返回。
这样，我开发一个新功能，这个新包就要被修改一次。 MY GOD！！
2. 还有一种方法，那么就是IoC
实现机制上，既然用了反射，那么底层的包就不需要引用高层的包，只要反射成为一个接口，那么就能够直接调用。
为什么叫做IoC
现在总算明白了。因为我的操作是在底层的，但是使用了高层的功能。那么形象的说，就是一种“反向”！把高级的功能放进底层的包里面去运行，就是一种”注入“。
按照OO的传统，应该是高级功能继承低级功能，这样越开发，用户使用的包就越高级。
但是，这样维护起来太麻烦了，每次添加一个新功能，都要重新编译一个新的包。
但是IoC不一样，只要开发好了接口，部署到用户之后，以后基于这个接口开发新的功能，只要把新的包同样部署到用户，然后修改配置文件，那么旧的包依然能够调用。
嗨。。。看来国外同行的思维还真是形象。