首页 > 代码库 > IOC(Inversion of Control)设计模式

IOC(Inversion of Control)设计模式

控制反转提倡实现松耦合层、组件和类的设计原则,颠倒程序的控制流程。IOC使用分离执行特定问题处理代码的概念;

IOC意味着将你设计好的对象交给容器控制,而不是传统的在你的对象内部直接控制。由IOC容器来控制对象的创建;通过IOC,消除组件或者模块间的直接依赖;.Net Framework建立在控制反转的思想基础上;强调控制权的反转,体现控制流程的依赖倒置;

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

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

反转: 由容器来帮忙创建及注入依赖对象;由容器帮我们查找及注入依赖对象,对象只是被动的接受依赖对象;

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

控制反转一般分为两种类型:依赖注入(Dependency Injection,简称DI)和依赖查找(Dependency Lookup)。

服务定位(service location):

依赖注入(dependency injection,DI):组件之间依赖关系由容器在运行期决定,形象的说,即由容器动态的将某个依赖关系注入到组件之中依赖注入的目的并非为软件系统带来更多功能,而是为了提升组件重用的频率,并为系统搭建一个灵活、可扩展的平台。

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

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

谁依赖于谁:当然是应用程序依赖于IoC容器

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

谁注入谁:很明显是IoC容器注入应用程序某个对象,应用程序依赖的对象

注入了什么:就是注入某个对象所需要的外部资源(包括对象、资源、常量数据)

依赖注入的常见三种方式:

接口注入(interface injection):将对象间的关系转移到一个接口,以接口注入控制;

构造器注入(Constructor injection):客户类在类型构造时,将服务类实例以构造函数参数的形式传递给客户端,服务类实例一旦注入将无法更改;

技术分享

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

技术分享

还有一个是.Net特有的 Attribute注入

 

IOC(Inversion of Control)设计模式