1,关于IOC模式
先看一些名词含义:
IOC: Inversion of control 控制反转,简称
DI: Dependency Injection 依赖注入,简称
DIP: 依赖倒置原则 一种软件架构设计的原则(抽象概念),“设计模式使用场景及原则”一篇中介绍过设计模式的几种原则之一。
IoC容器:依赖注入的框架,用来映射依赖,管理对象创建和生存周期(DI框架)。
(1)IOC和DI,是站在不同角度的描述,本身是同一个概念
先说说这两个对于初次接触到的同学难以理解的概念,首先这两个东东是一回事,只是因为角度不同,有了两个名字。
举个不太恰当的例子,比如一个人,爸爸叫你儿子,爷爷叫你孙子,那这个儿子和孙子都是你,是同一个人,只是站的角度不同,这么说容易理解了吧。
依赖注入(DI)是从应用程序的角度在描述,可以把依赖注入描述完整点:应用程序依赖容器创建并注入它所需要的外部资源;
而控制反转(IOC)是从容器的角度在描述,描述完整点:容器控制应用程序,由容器反向的向应用程序注入应用程序所需要的外部资源。
(2)是一种大粒度的设计模式
和GOF的23种设计模式相比较。IOC模式(通常中文称"依赖注入"或“依赖倒置”),由于出现时间比较晚,没有被收录。
其次和23种设计模式相比较,它的粒度更大一些,和MVC模式一样,通常到架构层面了,而不是具体代码片段级别。理解到这里就可以了。
但它仍然是设计模式,只是和23种设计模式比,23种模式是战术层面,IOC模式是战略层面的。
依赖注入映射到面向对象程序开发中就是:高层类应该依赖底层基础设施来提供必要的服务。
编写松耦合的代码说起来很简单,但是实际上写着写着就变成了紧耦合。
一个比较难理解的正式定义如下:
依赖注入(Dependency Injection),是这样一个过程:由于某客户类只依赖于服务类的一个接口,而不依赖于具体服务类,所以客户类只定义一个注入点。
在程序运行过程中,客户类不直接实例化具体服务类实例,而是客户类的运行上下文环境或专门组件负责实例化服务类,然后将其注入到客户类中,保证客户类的正常运行。
下面的说明比较容易理解:
理解DI的关键是:“谁依赖谁,为什么需要依赖,谁注入谁,注入了什么”,那我们来深入分析一下:
●谁依赖于谁:当然是应用程序依赖于IoC容器;
●为什么需要依赖:应用程序需要IoC容器来提供对象需要的外部资源;
●谁注入谁:很明显是IoC容器注入应用程序某个对象,应用程序依赖的对象;
●注入了什么:就是注入某个对象所需要的外部资源(包括对象、资源、常量数据)。
IoC和DI由什么关系呢?其实它们是同一个概念的不同角度描述,由于控制反转概念比较含糊(可能只是理解为容器控制对象这一个层面,很难让人想到谁来维护对象关系),
所以2004年大师级人物Martin Fowler又给出了一个新的名字:“依赖注入”,相对IoC 而言,“依赖注入”明确描述了“被注入对象依赖IoC容器配置依赖对象”。
2,依赖注入的作用
依赖注入不是目的,它是一系列工具和手段。
最终的目的是帮助我们开发出松散耦合(loose coupled)、可维护、可测试的代码和程序。
这条原则的做法是大家熟知的面向接口,或者说是面向抽象编程。
常见的三层架构中,虽然表面上表现、业务、数据分层设计。但在数据库层往往会产生一些与具体业务有关的类,而且如果不严格遵循代码规范,会导致产生表现层直接new数据层的情况。
如果要换个数据源呢?假如不使用ADO.NET等试,改为Http呢?这将是领域逻辑层和表现层与之耦合的代码要进行大量更动。
这样使得整个系统紧耦合,并且可测试性差。
在系统设计过程中,各个类从上层到下层类之间必然会产生耦合,如果完全没有耦合,那么这个类或程序集就可以从项目中移除了。
因此如何使之达到松散耦合,从而提高可测试性呢?依赖注入将能很好的解决上述问题。
3,IOC模式应用示例
下面以一个简单购物过程为例来说明IOC模式如何实现松散耦合。
(1)传统三层模式
代码如下:
public class DalSqlServer { public void Add() { Console.WriteLine("在数据库中添加一条订单!"); } }
public class Order { private readonly DalSqlServer dal = new DalSqlServer();//添加一个私有变量保存数据库操作的对象 public void Add() { dal.Add(); } }