控制反转(IOC)模式

时间:2021-12-25 04:20:11

控制反转(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):客户类在类型构造时,将服务类实例以构造函数参数的形式传递给客户类,服务类实例一旦注入将无法更改;

控制反转(IOC)模式

属性注入(Setter injection):通过客户类属性设置的方式,将服务器类实例在运行时设定为客户类属性;

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

控制反转(IOC)模式

.Net特有的 Attribute注入:

服务定位(service location):