首页 > 代码库 > 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)设计模式