.NET IoC模式依赖反转(DIP)、控制反转(Ioc)、依赖注入(DI)

依赖倒置原则(DIP)

依赖倒置(Dependency Inversion Principle,缩写DIP)是面向对象六大基本原则之一。他是指一种特定的的解耦形式,使得高层次的模块不依赖低层次的模块的实现细节,依赖关系被颠倒(反转),从而使得低层次模块依赖于高层次模块的需求抽象.

该原则规定:

  • 高层次的模块不应该依赖低层次模块,二者都应该依赖其抽象接口.
  • 抽象接口不应该依赖于具体实现,而具体实现则应该依赖于抽象接口.

通过如下一个简单的示例,我们来看一下,我们通过一个简单地下单流程向我们的用户发送相关的短信或者邮件.

public SendingEmail
{
 public void Send(string message){
  //do something
 }
}

public Ordering
{
 SendingEmail _sendingEmail=null;
 public void Order(string message){
  //Order business operation
  if(_sendingEmail == null)
  {
   _sendingEmail=new SendingEmail();
  }
  _sendingEmail.Send(message);
 }
}

这样看我们的代码没问题,目前只要我们完成了订单操作那么,那么则会触发发送功能,但是他却违反了DIP,因为Ordering类依赖于SendingEmail类,而SendingEmail类不是抽象类,而是一个具体的类.那我们再来想一个如果这时候业务口的人过来向我们提出了一个新的需求,要求我们改为短信而不是Email,那么我们需要怎么改?

public class SendingSMS
{
 public void Send(string message){
  //do something
 }
}
public Ordering
{
 SendingEmail _sendingEmail=null;
 SendingSMS _sendingSMS=null;
 bool isSendingSMS=true;
 public void Order(string message){
  //Order business operation
  if(isSendingSMS){
   if(_sendingSMS == null)
   {
    _sendingSMS=new SendingSMS();
   }
   _sendingSMS.Send(message);
  }else{
   if(_sendingEmail == null)
   {
    _sendingEmail=new SendingEmail();
   }
   _sendingEmail.Send(message);
  }

 }
}

根据上述需求我们不得不创建更多的类,并且在Ordering类中声明他,最后我们还需要使用IF ELSE语句来决定使用SMS还是使用电子邮件.但是当我们有更多这种处理操作后,那么可能比现在还混乱,这就意味着我们必须在Ordering类中声明更多新的具体类的实例.

我们需要抽离出来一种方式,让高级模块去依赖于抽象,用它来代替我们实现类,该抽象将映射到实现类.

控制反转(IoC)

控制反转(Inversion of Control,缩写为IOC)是面向对象中的设计原则,他可以帮助我们使高层模块依赖于抽象,而不是底层模块的具体实现.换句话说,他有助于实现(依赖倒置原则——DIP).

public interface ICustomerCommunication
{
 void Send(string message);
}
然后我们修改SendingEmail和SendingSMS类以从ICustomerCommunication接口继承.

public class SendingEmail:ICustomerCommunication
{
 public void Send(string message){
  //do something
 }
}

public class SendingSMS:ICustomerCommunication
{
 public void Send(string message){
  //do something
 }
}

我们再来修改一下Ordering类以使用该抽象接口

public Ordering
{
 ICustomerCommunication _customerComm=null;
 bool isSendingSMS=true;
 public void Order(string message){
  //Order business operation
  if(isSendingSMS){
   if(_customerComm == null)
   {
    _customerComm=new SendingSMS();
   }
   _customerComm.Send(message);
  }else{
   if(_customerComm == null)
   {
    _customerComm=new SendingEmail();
   }
   _customerComm.Send(message);
  }

 }
}

通过如上修改我们做的控制反转更符合DIP.现在我们的高级模块只需要依赖于抽象,而不用去依赖实现.

依赖注入(DI)

依赖注入(Depeondency Injection,缩写为DI)是实现控制反转的一种方式.常用的依赖注入方法有3种:

  • 构造函数注入
  • 方法注入
  • 属性注入

虽然说通过上面代码我们实现了IoC,并且Ordering类依赖于ICustomerCommunication抽象,但我们仍然在Ordering类中使用了实现类,这使用我们无法在类于类之间完全解耦.

 if(isSendingSMS){
 if(_customerComm == null)
 {
  _customerComm=new SendingSMS();
 }
  _customerComm.Send(message);
 }else{
  if(_customerComm == null)
  {
   _customerComm=new SendingEmail();
  }
  _customerComm.Send(message);
 }

那我们再来说说DI,DI主要帮助我们将实现注入到抽象的类(ICustomerCommunication接口)中.DI的主要减少类之间的耦合,并且将抽象和具体实现的绑定移除依赖类.

构造函数注入

通过构造函数注入我们将实现类的对象传递给依赖类的构造函数,并将其分配给这个接口.

public class Ordering
{
 ICustomerCommunication _customerComm=null;
 public Ordering(ICustomerCommunication customerComm){
  _customerComm=customerComm;
 }
 public void Order(string message){
  _customerComm.Send(message);
 }
}

在上面的代码中,构造函数将采用实现类对象绑定到接口中.如果我们将SendingSMS的实现传递给这个类,我们要做的就是声明一个SendingSMS类的实例,然后将其传递给Ordering的构造函数,如下所示:

方法注入

通过使用构造函数注入,我们将不得不在Ordering类的生存期内使用实现类的实例SendingSMS或SendingEmail类.现在如果要在每次调用该方法时传递实现类的实例,则必须使用方法注入.

public class Ordering
{
 public void Order(ICustomerCommunication customerComm,string message){
  _customerComm=customerComm;
  _customerComm.Send(message);
 }
}

调用方式如下所示

SendingSMS sendingSMS=new SendingSMS();
Ordering ordering=new Ordering(sendingSMS);
ordering.Order(sendingSMS,"msg");

属性注入

通过如上描述我们知道了构造函数注入方法在整个生命周期中使用依赖类,而方法注入是将我们的注入直接去限于该方法中,然后我们再去了解一下属性注入

public class Ordering
{
 public ICustomerCommunication customerComm {get;set;}
 public void Order(string message){
  _customerComm.Send(message);
 }
}

调用方式如下所示

SendingSMS sendingSMS=new SendingSMS();
Ordering ordering=new Ordering(sendingSMS);
ordering.customerComm=sendingSMS;
ordering.Order("msg");

其实构造函数注入是实现DI最常用的方法.如果需要在每个方法调用上传递不同的依赖关系,则可以使用方法注入属性注入的使用还是比较少的.

Reference

https://zh.wikipedia.org/wiki/控制反转

https://zh.wikipedia.org/zh-hans/依赖反转原则

到此这篇关于.NET IoC模式依赖反转(DIP)、控制反转(Ioc)、依赖注入(DI)的文章就介绍到这了,更多相关.NET IoC模式依赖反转、控制反转、依赖注入内容请搜索我们以前的文章或继续浏览下面的相关文章希望大家以后多多支持我们!

(0)

相关推荐

  • 解读ASP.NET 5 & MVC6系列教程(7):依赖注入

    在前面的章节(Middleware章节)中,我们提到了依赖注入功能(Dependency Injection),ASP.NET 5正式将依赖注入进行了全功能的实现,以便开发人员能够开发更具弹性的组件程序,MVC6也利用了依赖注入的功能重新对Controller和View的服务注入功能进行了重新设计:未来的依赖注入功能还可能提供更多的API,所有如果还没有开始接触依赖注入的话,就得好好学一下了. 在之前版本的依赖注入功能里,依赖注入的入口有MVC中的IControllerFactory和Web A

  • .NET学习笔记之默认依赖注入

    介绍 不要依赖于具体的实现,应该依赖于抽象,高层模块不应该依赖于底层模块,二者应该依赖于抽象.简单的说就是为了更好的解耦.而控制反转(Ioc)就是这样的原则的其中一个实现思路, 这个思路的其中一种实现方式就是依赖注入(DI).ASP.NET Core内置有对依赖注入(DI)的支持,开发者只需要定义好接口后,在Startup.cs的ConfigureServices方法里使用对应生命周期的绑定方法即可. 只要是用new实例化的都是存在依赖的. 生命周期 AddSingleton→AddTransi

  • ASP.NET MVC实现依赖注入的完整过程

    前言 在java的spring中有自动注入功能,使得代码变得更加简洁灵活,所以想把这个功能移植到c#中,接下来逐步分析实现过程 1.使用自动注入场景分析 在asp.net mvc中,无论是什么代码逻辑分层,最终的表现层为Controller层,所以我们注入点就是在Controller中,这里我们需要替换默认的ControllerFactory,扫描代码中标记需要注入的对象,进行实例化注入 public class FastControllerFactory : DefaultController

  • 在.NET Core控制台程序中如何使用依赖注入详解

    背景介绍 Dependency Injection:又称依赖注入,简称DI.在以前的开发方式中,层与层之间.类与类之间都是通过new一个对方的实例进行相互调用,这样在开发过程中有一个好处,可以清晰的知道在使用哪个具体的实现.随着软件体积越来越庞大,逻辑越来越复杂,当需要更换实现方式,或者依赖第三方系统的某些接口时,这种相互之间持有具体实现的方式不再合适.为了应对这种情况,就要采用契约式编程:相互之间依赖于规定好的契约(接口),不依赖于具体的实现.这样带来的好处是相互之间的依赖变得非常简单,又称松

  • .NET Core中依赖注入AutoMapper的方法示例

    本文主要介绍了关于.NET Core中依赖注入AutoMapper的相关内容,分享出来供大家参考学习,下面话不多说了,来一起看看详细的介绍: 最近在 review 代码时发现同事没有像其他项目那样使用 AutoMapper.Mapper.Initialize() 静态方法配置映射,而是使用了依赖注入 IMapper 接口的方式 services.AddSingleton<IMapper>(new Mapper(new MapperConfiguration(cfg => { cfg.Cr

  • ASP.NET Core 过滤器中使用依赖注入知识点总结

    如何给过滤器ActionFilterAttribute也用上构造函数注入呢? 一般自定义的过滤器直接用特性方式标识就能使用 [ContentFilter] 因为构造函数在使用的时候要求传参,然后我们可以使用这个 ServiceFilter 在ASP.NET Core里,我们可以使用ServiceFilter来完成这个需求. ServiceFilter允许我们解析一个已经添加IoC容器的服务,因此我们需要把ContentFilter注册一下. services.AddScoped<ContentF

  • 详解ASP.NET Core 在 JSON 文件中配置依赖注入

    前言 在上一篇文章中写了如何在MVC中配置全局路由前缀,今天给大家介绍一下如何在在 json 文件中配置依赖注入. 在以前的 ASP.NET 4+ (MVC,Web Api,Owin,SingalR等)时候,都是提供了专有的接口以供使用第三方的依赖注入组件,比如我们常用的会使用 Autofac.Untiy.String.Net 等,这些第三放依赖注入组件基本上都提供了一套配置注入或者配置生命周期的方式,除了直接配置到类里面之外,还提供了要么使用 xml 文件,要么使用 json 等,那么在新的

  • 详解asp.net core 依赖注入

    前言 好久没有写微博了,因为前段时间由于家庭原因决定从工作了3年多的北京转移到上海去.依赖注入在学习net core的时候也有写过类似的东西,只是实践的较少,结果来到上海新公司系统框架涉及到了这块知识点,所以在了解完自己的项目之后决定做一些相关的总结.接下来就让我们先来了解hewi依赖注入. 什么是依赖注入 依赖注入,全称是"依赖注入到容器", 容器(IOC容器)是一个设计模式,它也是个对象,你把某个类(不管有多少依赖关系)放入这个容器中,可以"解析"出这个类的实例

  • 详解ASP.NET Core 中的框架级依赖注入

    1.ASP.NET Core 中的依赖注入 此示例展示了框架级依赖注入如何在 ASP.NET Core 中工作. 其简单但功能强大,足以完成大部分的依赖注入工作.框架级依赖注入支持以下 scope: Singleton - 总是返回相同的实例 Transient - 每次都返回新的实例 Scoped - 在当前(request)范围内返回相同的实例 假设我们有两个要通过依赖注入来进行工作的工件: PageContext - 自定义请求上下文 Settings - 全局应用程序设置 这两个都是非常

  • .NET IoC模式依赖反转(DIP)、控制反转(Ioc)、依赖注入(DI)

    依赖倒置原则(DIP) 依赖倒置(Dependency Inversion Principle,缩写DIP)是面向对象六大基本原则之一.他是指一种特定的的解耦形式,使得高层次的模块不依赖低层次的模块的实现细节,依赖关系被颠倒(反转),从而使得低层次模块依赖于高层次模块的需求抽象. 该原则规定: 高层次的模块不应该依赖低层次模块,二者都应该依赖其抽象接口. 抽象接口不应该依赖于具体实现,而具体实现则应该依赖于抽象接口. 通过如下一个简单的示例,我们来看一下,我们通过一个简单地下单流程向我们的用户发

  • php中Ioc(控制反转)和Di(依赖注入)

    先看一个例子: <?php class A { public $b; public $c; public function A() { //TODO } public function Method() { $this->b=new B(); $this->c=new C(); $this->b->Method(); $this->c->Method(); //TODO } } class B { public function B() { //TODO } pu

  • PHP控制反转(IOC)和依赖注入(DI)

    先看一个例子: <?php class A { public $b; public $c; public function A() { //TODO } public function Method() { $this->b=new B(); $this->c=new C(); $this->b->Method(); $this->c->Method(); //TODO } } class B { public function B() { //TODO } pu

  • 轻松理解Java面试和开发中的IoC(控制反转)

    IoC的概念介绍 控制反转(IOC)模式(又称DI:Dependency Injection)就是Inversion of Control,控制反转.在Java开发中,IoC意 味着将你设计好的类交给系统去控制,而不是在你的类内部控制.这称为控制反转. 控制反转(Inversion of Control,英文缩写为IoC)是框架的重要特征,做到控制反转需要一个容器来实现,就是我们所说的IoC容器,最常见的IoC容器是Spring. 控制反转从字面意思看来不是很好理解,其实就是将创建管理对象的工作

  • 自己编写IOC控制反转及AOP面向切面

    1.概念 IOC:Inversion of control 控制反转 控制:指的是对象创建(实例化.管理)的权利 反转:控制权交给外部环境了(spring框架.IoC容器) 传统开发⽅式:⽐如类A依赖于类B,往往会在类A中new⼀个B的对象 IoC思想下开发方式:我们不⽤⾃⼰去new对象了,⽽是由IoC容器(Spring框架)去帮助我们实例化对象并且管理它,我们需要使⽤哪个对象,去问IoC容器要即可. 解决的问题:解决对象之间的耦合问题,避免new关键字 Ioc和DI区别:IOC和DI是从不同角

  • Spring依赖注入和控制反转详情

    目录 控制反转 什么是依赖? 紧耦合对象 松散耦合对象 依赖注入 为什么我们需要 IoC 容器? 以下是上面的重要问题 控制容器反转(IoC 容器) Spring 依赖注入 总结 前言: 在我们开始做任何事情之前,让我们先了解一下什么是控制反转.学习依赖注入和控制反转的概念,然后借助代码示例了解 Spring 框架如何支持它们. 控制反转 在我们开始做任何事情之前,让我们先了解一下什么是控制反转. 控制反转是面向对象编程中使用的术语,通过该术语,对象或对象集的控制权被赋予框架或由框架提供的容器.

  • PHP依赖注入(DI)和控制反转(IoC)详解

    首先依赖注入和控制反转说的是同一个东西,是一种设计模式,这种设计模式用来减少程序间的耦合,鄙人学习了一下,看TP官网还没有相关的文章,就写下这篇拙作介绍一下这种设计模式,希望能为TP社区贡献一些力量. 首先先别追究这个设计模式的定义,否则你一定会被说的云里雾里,笔者就是深受其害,百度了N多文章,都是从理论角度来描述,充斥着大量的生涩词汇,要么就是java代码描述的,也生涩. 不管怎么样,总算弄清楚一些了,下面就以php的角度来描述一下依赖注入这个概念. 先假设我们这里有一个类,类里面需要用到数据

  • ASP.NET Core依赖注入系列教程之控制反转(IoC)

    前言 ASP.NET Core在启动以及后续针对每个请求的处理过程中的各个环节都需要相应的组件提供相应的服务,为了方便对这些组件进行定制,ASP.NET通过定义接口的方式对它们进行了"标准化",我们将这些标准化的组件称为服务,ASP.NET在内部专门维护了一个DI容器来提供所需的服务.要了解这个DI容器以及现实其中的服务提供机制,我们先得知道什么是DI(Dependence Injection),而一旦我们提到DI,又不得不说IoC(Inverse of Control). 一.流程控

  • .NET Core使用Autofac容器的DI依赖注入,IOC控制反转及AOP切面编程

    目录 Autofac 容器 Autofac 多种注入方式 Autofac 生命周期 Autofac 支持配置文件 Autofac 整合 .NET 5 MVC Autofac 支持控制器属性注入 Autofac 单实例多实现 Autofac 支持 AOP Autofac 容器 Autofac 是一款.NET IoC 容器 . 它管理类之间的依赖关系, 从而使 应用在规模及复杂性增长的情况下依然可以轻易地修改 . 它的实现方式是将常规的.net类当做组件处理. 安装 NuGet 程序包: Autof

  • spring中IOC控制反转依赖注入和new对象的区别说明

    目录 IOC控制反转依赖注入和new对象的区别 new对象 依赖注入 spring的IOC容器比New对象究竟好在哪 IOC控制反转依赖注入和new对象的区别 spring默认是单例模式的,依赖注入其中操作的都是一个对象 new对象 单例中如果要做到注入的效果就是在类的头部进行实例化对象,这个时候该对象不管使用与否都贯穿该类的始终.该类对象不被回收,这个实例化对象也不会被回收,因为存在引用状态.如果要使用多例对象则最好使用new创建对象而不是依赖注入,即使依赖注入有多例模式也不推荐. 依赖注入:

随机推荐