控制反转基本上说的是功能调用者与功能实现者之间应该如何交互，即二者之间没有直接的强耦合（调用者new一个被调用者），而是都依赖同一个抽象，这个抽象规定了二者交互的接口。反转的意思是实现了依赖倒置，在程序中高层不是根据低层的接口来写调用，而是倒过来，高层根据需要定义接口，低层向上负责实现这个接口。这体现了自顶向下的设计思路和自底向上的实现方法，使软件代码具有自然的可读性，以及关注点的分离。
IoC容器是实现IoC的框架，具体包括了接口与实现的关系配置功能和获取实现对象的功能，其中获取实现对象的功能大体对应了设计模式中的工厂模式，下面简要分析对比一下原生态new调用，工厂模式调用，和IoC容器调用：
为了对比方便，在分析原生态调用之前先假设一个前提，那就是功能被某个具体的类实现了。直接调用有最好的性能，但可维护性和可测试性很差，比如想要修改一个功能的实现，有2种实现方法A和B，A是一个巨大的改变，也就是适合于新写一个类来实现，B是一个较小的改变，可以直接修改类的内部结构。假如用A方案，而系统又有多处引用，甚至还需要注意构造函数及其参数的变化，那么意味着多个修改量，这违背了TRY原则，对开发是一个负担。假如使用了B方案，那就要注意内部实现的改变是否会影响外部环境，是否有使修改不封闭的地方。而可测试性就不必多说了，因为是直接new的，所以无法Moq，导致无法完美的做单元测试。
当直接用工厂模式时，需要先做抽象，即把功能代码分成抽象和实现两部分，功能调用者调用工厂提供的方法获得具体的实现对象，这确保了系统是面向接口编程的，帮助编程者写出高内聚低耦合的逻辑。同时也引发了一些问题，比如可能有较多的工厂类需要维护，功能调用者与工厂类之间又有耦合，假如用抽象工厂模式来解耦，又需要增加配置文件的内容。
使用IoC容器可以非常方便的定义符合某个接口的实现对象的获取策略，能够对对象的生命周期做配置和管理，而无需编写和维护工厂代码，拥有最佳的可维护性和可测试性。
