控制反转（IOC）模式

控制反转(Inversion of Control)：提倡实现松耦合层、组件和类的设计原则，颠倒程序的控制流程。IoC使用分离执行特定问题处理代码的概念；

IoC意味着将你设计好的对象交给容器控制，而不是在你的对象内部直接控制,由IOC容器来控制对象的创建；

通过IoC,消除组件或者模块间的直接依赖；.Net Framework建立在控制反转的思想基础上；强调控制权的反转，体现控制流程的依赖倒置；

控制:  IOC容器控制了对象, 主要控制了外部资源获取（不只是对象包括比如文件等）;

正转: 由我们自己在对象中主动控制去直接获取依赖对象;

反转: 由容器来查找/创建及注入依赖对象，对象只是被动的接受依赖对象;

IoC容器: 帮对象找相应的依赖对象并注入，而不是由对象主动去找。把创建和查找依赖对象的控制权交给了容器，由容器进行注入组合对象，所以对象与对象之间是松散耦合;

IOC中最基本的技术就是“反射(Reflection)”编程，通俗来讲就是根据给出的类名（字符串方式）来动态地生成对象，这种编程方式可以让对象在生成时才被决定到底是哪一种对象。.Net中NHibernate、Spring.NET框架都是把”反射“做为最基本的技术手段。

控制反转主要由两种类型实现：依赖注入（Dependency Injection,DI）和依赖查找（Dependency Lookup）。

依赖注入（dependency injection）：组件之间依赖关系由容器在运行期决定，即由容器动态的(根据上下文环境)将某个依赖关系注入到组件之中。依赖注入的目的并非为软件系统带来更多功能，而是为了提升组件重用的频率，并为系统搭建一个灵活、可扩展的平台。

体现了“做什么”和“怎么做”的关注点分离，依赖注入体现了对实例生命周期（特别是实例创建）和组件装配的关注点分离；

理解DI的关键是：“谁依赖谁，为什么需要依赖，谁注入谁，注入了什么”:

●谁依赖于谁：当然是应用程序依赖于IoC容器；

●为什么需要依赖：应用程序需要IoC容器来提供对象需要的外部资源；

●谁注入谁：很明显是IoC容器注入应用程序某个对象，应用程序依赖的对象；

●注入了什么：就是注入某个对象所需要的外部资源（包括对象、资源、常量数据）。

过程：由于某客户类只依赖于服务类的一个接口，而不依赖于具体服务类，所以客户类只定义一个注入点。在程序运行过程中，客户类不直接实例化具体服务类实例，而是客户类的运行上下文环境或专门组件负责实例化服务类，然后将其注入到客户类中，保证客户类的正常运行。

依赖注入（传递依赖关系）的常见三种方式：

接口注入（interface injection）:将对象间的关系转移到一个接口，以接口注入控制；

接口注入是现在不甚提倡的一种方式，因为它强制被注入对象实现不必要的接口，带有侵入性。利用反射机制达到创建服务类；

构造器注入（Constructor injection）:客户类在类型构造时，将服务类实例以构造函数参数的形式传递给客户类，服务类实例一旦注入将无法更改；

属性注入（Setter injection）:通过客户类属性设置的方式，将服务器类实例在运行时设定为客户类属性；

在客户类中设置一个服务类接口类型的数据成员，并设置一个Set方法作为注入点，这个Set方法接受一个具体的服务类实例为参数，并将它赋给服务类接口类型的数据成员。

.Net特有的 Attribute注入:

服务定位（service location）：