.NET Core Web API使用依赖注入(DI)进行服务配置一

  ASP.NET Core的框架的设计从头到尾都是模块化的,并且遵循良好的软件工程实践。在面向对象的程序设计中,SOLID经受住了时间的考验。ASP.NET Core已经把依赖注入融入了核心框架。不管你自己是否想把依赖注入运用到自己的代码中,ASP.NET Core框架已经把依赖注入当成了一个基本概念。

  SOLID是 Single responsibility, Open-closed, Liskov substitution, Interface segregation, Dependeny inversion的简写:https://zh.wikipedia.org/zh-hans/SOLID_(面向对象设计)

依赖注入的介绍参考链接:https://www.martinfowler.com/articles/injection.html

1.明白依赖注入的好处

  在简单应用程序中我们使用不到依赖注入,但当应用程序变得复杂得时候,依赖注入(DI)可以作为一个伟大的工具来控制代码的复杂性。

  让我们看下面一个例子,当不使用DI时,一个用户在你的Web应用程序上注册后,你想给它发送一封邮件,下面的代码展示了你可能会在最初的时候这样处理问题。

  在这个例子中,当一个新用户注册你的Web应用程序时,在UserControllor中RegeditUser

将执行。首先创建一个EmailSender类的实例,并且调用SendEmail()方法去发送邮件。在这个例子中,你可以设想将看到以下的内容:

Console.WriteLine将会执行发送email。

  如果EmailSender类像这个例子一样简单并且没有依赖项,你可能不会考虑使用其它方法来创建对象。在某种程度上,你可能时对的。但是如果你稍后更新EmailSender的实现逻辑,发现它并不能实现自身邮件发送的全部逻辑。

实际上,EmailSender在发送邮件时需要做大量的事情:

1.创建一个email消息

    2.配置email服务的设置

3.将邮件发送给emial服务器

  如果在一个类中实现以上功能,将会违背单位职责原则(SRP),所以不能让EmialSender依赖其它服务。下图将会展示Web应用程序的依赖将会是怎样的。UserController想要使用EmailSender去发送邮件,但是如果要这样做,首先需要创建一个MessageFactory,NetworkClient,EmailServerSettings对象给EmailSender提供依赖。

  每一个类都需要大量的依赖,在这个例子中UserController作为“底部”的类,需要知道如何创建它所依赖的每一个类,以及每一个类的依赖关系。

多依赖服务的例子如下:

NetworkClient依赖的实例代码如下:

  用这样的方式可能觉得很麻烦,但这样的依赖链却是很常见的。实际上,你的代码中并没有这样写,那你的类将会很庞大,并且违背了单一职责原则。当你手动创建依赖时,发送邮件时是没有DI的。代码如下所示:

  上述代码示例变成了一些粗糙的代码。当在UserController调用时,为提高EmailSender的设计性,以分离出不同的职责,这成为了一个麻烦事。上述代码有以下问题。

1.没有遵循单一职责原则-我们的代码同时负责创建EmailSender实例并且使用它发送邮件。

2.相当大的方法代码-上面的RegeditUser方法,只有最后两行代码才有用。很难读懂这个方法的真正目的是什么。

3.与实现绑定-如果你决定去重构EmialSender并且去添加另一个依赖,你需要去更新它每一个使用的地方。

  UserController已经明确的依赖了EmailSender类,并且手动创建了这个对象的实例作为RegeditUser方法的一部门。在阅读源代码时仅仅知道UserController使用了EmailSender。相比之下,EmialSender已经明确依赖了NetworkClient和MessageFactory,并且在构造函数中进行了初始化。同样的,NetworkClient已经明确的依赖了EmailServerSetting类。

  依赖注入旨在决绝反转依赖链。以代替UserController去手动的创建依赖,深入代码实现的细节中,已经创建了通过构造函数注入EmailSender创建的实例。

  现在,很明显了,需要一些事情去创建对象,所以这些代码对象需要在某处存活。负责创建对象的服务称为 DI 容器或IoC容器。常见的DI容器有:Autofac,StructureMap, Unity, Ninject, Simple Injector . . .

  使用DI容器的关系图如下:

  此时UserController中的代码如下图所示:

 

  DI容器的优势就说职责单一:创建对象或服务。向容器请求一个服务的实例,并且计算出增氧创建一个依赖图,但这些都依赖于怎样配置它们。

  使用明显的依赖的优势就是,在一个方法中你永远不会在写混乱的方法了。DI容器可以检查你的服务的构造方法并且计算出代码自身中重要的部分。DI容器是可以配置的,所以你可以手动创建可提供的服务的实例。它可以通过接口让你的代码保持松耦合。

  在面向对象语言中耦合是一个很重要的概念。它指出一个类怎样去依赖其它类并且执行它自己的函数。松耦合的代码不需要知道一个特别组件的很多细节,就直接可以去使用它。

  在UserController中初始化EmailSender就说紧耦合的,你需要直接的创建EmialSender的实例。一个难点就是这个代码很难去测试,任何尝试测试UserController的方法将导致发送邮件。将 EmailSender 作为构造函数参数,并删除创建对象的职责将会减少代码的耦合。如果EmialSender的实现变了,让它依赖于另一个实现,不需要在同时更新更新UserController。

通过接口变成在设计模式中是一种常见的方法,它减少了系统中的耦合。并且还不会绑定到单一的实现,并且这也让类变的可以测试。所以可以创建一个IEmialSender接口,让EmailSender实现它:

用户控制器的代码如下:

  现在UserController已经不用关心依赖是怎么实现的了,仅仅实现了IEmailSender接口并且暴露了SendEmail方法。现在应用程序的代码已经独立于实现了。现在已经实现了松耦合的代码了。但是又有一个问题:应用程序怎么知道使用EmailSender去代替DummyEmailSender,DI容器告诉你答案:当你需要IEmailSender,使用EmailSender去注册。

  怎样在DI容器中注册接口和实现非常依赖DI容器的实现方式,但是基本所有DI容器的原则都是一样的。ASP.NET Core包含开箱即用的简单DI容器,所以让我们看下在一个典型的请求中怎样使用它。

2.在ASP.NET Core中使用依赖注入

  本章详细的内容将在下篇博客中详细说明。

原文地址:https://www.cnblogs.com/fengye310/p/11008950.html

时间: 2024-09-28 19:37:00

.NET Core Web API使用依赖注入(DI)进行服务配置一的相关文章

依赖注入(DI)与服务容器(IoC)

参考文章:http://www.yuansir-web.com/2014/03/20/%E7%90%86%E8%A7%A3php-%E4%BE%9D%E8%B5%96%E6%B3%A8%E5%85%A5laravel-ioc%E5%AE%B9%E5%99%A8/?preview 我们在建一个类时,在类的内部有可能会用到另外一个对象实例举个栗子: class User{ public function getUser(){ $db = new DB(); // 这里产生了对数据库连接类的依赖 $d

[ASP.NET Core 3框架揭秘] 依赖注入[5]: 利用容器提供服务

毫不夸张地说,整个ASP.NET Core框架是建立在依赖注入框架之上的.ASP.NET Core应用在启动时构建管道以及利用该管道处理每个请求过程中使用到的服务对象均来源于依赖注入容器.该依赖注入容器不仅为ASP.NET Core框架自身提供必要的服务,同时也是应用程序的服务提供者,依赖注入已经成为了ASP.NET Core应用的基本编程模式. 一.服务的注册与消费 为了让读者朋友们能够更加容易地认识.NET Core提供的依赖注入框架,我在"<一个迷你版DI框架>"中特

ASP.NET Core技术研究-探秘依赖注入框架

原文:ASP.NET Core技术研究-探秘依赖注入框架 ASP.NET Core在底层内置了一个依赖注入框架,通过依赖注入的方式注册服务.提供服务.依赖注入不仅服务于ASP.NET Core自身,同时也是应用程序的服务提供者. 毫不夸张的说,ASP.NET Core通过依赖注入实现了各种服务对象的注册和创建,同时也实现了面向抽象的编程模式和编程体验,提升了应用程序的扩展性. 今天,我们普及一下ASP.NET Core中依赖注入的一些基本知识. 一.服务的注册 我们通过创建一个ASP.NET C

ASP.NET Core 依赖注入(DI)

原文:ASP.NET Core 依赖注入(DI) ASP.NET Core的底层设计支持和使用依赖注入.ASP.NET Core 应用程序可以利用内置的框架服务将服务注入到启动类的方法中,并且应用程序服务也可以配置注入.由ASP.NET Core 提供的默认服务容器提供了最小功能集,并不是取代其他容器. 1.浅谈依赖注入 依赖注入(Dependency injection,DI)是一种实现对象和依赖者之间松耦合的技术,将类用来执行其操作的这些对象以注入的方式提供给该类,而不是直接实例化依赖项或者

[ASP.NET Core 3框架揭秘] 依赖注入:控制反转

ASP.NET Core框架建立在一些核心的基础框架之上,这些基础框架包括依赖注入.文件系统.配置选项和诊断日志等.这些框架不仅仅是支撑ASP.NET Core框架的基础,我们在进行应用开发的时候同样会频繁地使用到它们.对于这里提到的这几个基础框架,依赖注入尤为重要.ASP.NET Core应用在启动以及后续针对请求的处理过程中,它会依赖各种的组件提供服务.为了便于定制,这些组件一般会以接口的形式进行"标准化",我们将这些标准化的组件统一称为"服务(Service)"

话说 依赖注入(DI) or 控制反转(IoC)

首页 下载 扩展 应用 教程 代码 案例 资讯 讨论 全部 搜索 话说 依赖注入(DI) or 控制反转(IoC) 浏览:3641 发布日期:2014/03/20 分类:技术分享 科普:首先依赖注入和控制反转说的是同一个东西,是一种设计模式,这种设计模式用来减少程序间的耦合,鄙人学习了一下,看TP官网还没有相关的文章,就写下这篇拙作介绍一下这种设计模式,希望能为TP社区贡献一些力量. 首先先别追究这个设计模式的定义,否则你一定会被说的云里雾里,笔者就是深受其害,百度了N多文章,都是从理论角度来描

在Mac下创建ASP.NET Core Web API

在Mac下创建ASP.NET Core Web API 在Mac下创建ASP.NET Core Web API 这系列文章是参考了.NET Core文档和源码,可能有人要问,直接看官方的英文文档不就可以了吗,为什么还要写这些文章呢? 原因如下: 官方文档涉及的内容相当全面,属于那种大而全的知识仓库,不太适合初学者,很容易让人失去重要,让人掉入到具体的细节之中. 对于大多数人来讲开发语言只是工具,程序员都有一个通病,就是死磕工具,把工具学深.我认为在工具上没有必要投入太多时间,以能高效地完成日常的

在ASP.NET Core Web API中为RESTful服务增加对HAL的支持

HAL(Hypertext Application Language,超文本应用语言)是一种RESTful API的数据格式风格,为RESTful API的设计提供了接口规范,同时也降低了客户端与服务端接口的耦合度.很多当今流行的RESTful API开发框架,包括Spring REST,也都默认支持HAL规范,当RESTful API被调用后,服务端就会返回ContentType为application/hal+json的JSON内容,例如: { "_links": { "

ASP.NET Core Web API下事件驱动型架构的实现(一):一个简单的实现

很长一段时间以来,我都在思考如何在ASP.NET Core的框架下,实现一套完整的事件驱动型架构.这个问题看上去有点大,其实主要目标是为了实现一个基于ASP.NET Core的微服务,它能够非常简单地订阅来自于某个渠道的事件消息,并对接收到的消息进行处理,于此同时,它还能够向该渠道发送事件消息,以便订阅该事件消息的消费者能够对消息数据做进一步处理.让我们回顾一下微服务之间通信的几种方式,分为同步和异步两种.同步通信最常见的就是RESTful API,而且非常简单轻量,一个Request/Resp