开发者社区

文档建议反馈控制台

最新优惠活动

文章/答案/技术大牛

发布

我可以构建2个核心，它们可以一起工作(.net IServiceProvider )吗？

是的，您可以构建两个核心，并且它们可以一起工作。.NET中的IServiceProvider接口是一个用于解析依赖项的服务提供程序。它允许您在应用程序中使用依赖注入来管理对象之间的依赖关系。

依赖注入是一种设计模式，它通过将对象的创建和解析过程委托给外部容器来实现对象之间的解耦。通过使用IServiceProvider，您可以将依赖项注入到您的核心组件中，以实现更好的可测试性、可维护性和可扩展性。

在构建两个核心并使它们一起工作的情况下，您可以使用IServiceProvider来解析和注入依赖项。您可以将每个核心的依赖项注册到IServiceProvider中，并在需要时从中解析它们。这样，两个核心就可以共享相同的依赖项，并且它们可以一起工作。

以下是一些腾讯云相关产品和产品介绍链接地址，可以帮助您构建和管理.NET应用程序的云计算环境：

云服务器（CVM）：提供可扩展的云服务器实例，可满足您的计算需求。了解更多：https://cloud.tencent.com/product/cvm
云数据库MySQL版（TencentDB for MySQL）：可靠、高性能的云数据库服务，适用于.NET应用程序的数据存储需求。了解更多：https://cloud.tencent.com/product/cdb_mysql
云存储（COS）：安全、稳定的对象存储服务，适用于存储和管理.NET应用程序中的静态资源。了解更多：https://cloud.tencent.com/product/cos

请注意，以上链接仅供参考，您可以根据具体需求选择适合的产品和服务。

相关搜索:我可以访问CruiseControl.net构建标签吗？Rails 3.03和Rails 2.38 - 它们可以一起工作吗？我可以在.NET核心中获得私有构造函数吗？我可以在ASP net核心中返回504 HTTP代码吗我可以为ARM构建.Net Core3.0WPF项目吗？我可以将Prism 5与.NET 4.6.2一起使用吗 Factory Pattern在这里可以工作吗?我可以将它与多个独立对象一起使用吗？我可以在.net核心中设置每个区域的默认页面吗？我可以信任ASP.NET核心中IFormFile上的.Length属性吗？我可以在.NET 4.6/7站点上运行.NET核心应用程序吗？我可以在.Net核心web项目的.Net Dll中使用mtom调用Web服务吗？我可以在Windows Forms中使用实体框架核心6(使用.NET 5)吗？我可以在. net核心控制台应用程序中使用BackgroundService吗？我可以在常规的.NET项目中使用用Nuget核心编写的.NET包吗？我可以将Entity Framework与ASP.NET成员资格一起使用吗？即使我使用的是.Net NuGet 3.1，我也可以更新到.Net 5核心软件包吗？我可以将Conda与从源代码构建的python版本一起使用吗？我可以在127.0.0.1而不是本地主机上运行我的asp.net核心mvc项目吗我可以将多个图像堆叠在一起并在它们之间切换吗？HTML、CSS、Java脚本我可以在我的asp.net mvc核心内的根站点的url中添加静态名称吗？

相关搜索:

页面内容是否对你有帮助？

有帮助

没帮助

相关·内容

ASP.NET Core中GetService（）和GetRequiredService（）之间的区别

上篇文章《在.NET Core 3.0中的WPF中使用IOC图文教程》中，我们尝试在WPF中应用.NET Core内置的IOC进行编程，在解析MainWindow的时候我用了GetRequiredService<T>()方法，当时就在想这个GetRequiredService<T>()方法跟GetService<T>()到底有什么区别呢，于是乎，谷歌了一把，就发现了一篇文章来介绍他们区别的，然后尝试翻译了一把，希望对大家有所帮助。文章最后会给出原文链接，以下就是翻译内容：

02

ASP.NET Core中GetService（）和GetRequiredService（）之间的区别

上篇文章《在.NET Core 3.0中的WPF中使用IOC图文教程》中，我们尝试在WPF中应用.NET Core内置的IOC进行编程，在解析MainWindow的时候我用了GetRequiredService<T>()方法，当时就在想这个GetRequiredService<T>()方法跟GetService<T>()到底有什么区别呢，于是乎，谷歌了一把，就发现了一篇文章来介绍他们区别的，于是乎尝试翻译一把，希望对大家有所帮助。文章最后会给出原文链接，以下就是翻译内容：

06

ASP.NET Core管道详解[4]: 中间件委托链

ASP.NET Core应用默认的请求处理管道是由注册的IServer对象和HostingApplication对象组成的，后者利用一个在创建时提供的RequestDelegate对象来处理IServer对象分发给它的请求。而RequestDelegate对象实际上是由所有的中间件按照注册顺序创建的。换句话说，这个RequestDelegate对象是对中间件委托链的体现。如果将RequestDelegate替换成原始的中间件，那么ASP.NET Core应用的请求处理管道体现为下图所示的形式。[本文节选自《ASP.NET Core 3框架揭秘》第13章, 更多关于ASP.NET Core的文章请点这里]

02

学习ASP.NET Core, 怎能不了解请求处理管道[4]: 应用的入口——Startup

一个ASP.NET Core应用被启动之后就具有了针对请求的处理能力，而这个能力是由管道赋予的，所以应用的启动同时意味着管道的成功构建。由于管道是由注册的服务器和若干中间件构成的，所以应用启动过程中一个核心的工作就是完成中间节的注册。由于依赖注入在ASP.NET Core应用这得到非常广泛的应用，框架绝大部分的工作都会分配给我们预先注册的服务，所以服务注册也是启动WebHost过程的另一项核心工作。这两项在启动过程中必须完成的核心工作通过一个名为Startup的对象来承载。 [本文已经同步到《ASP.NET

05

查看.NET Core源代码通过Autofac实现依赖注入到Controller属性

在之前的文章【ASP.NET Core 整合Autofac和Castle实现自动AOP拦截】中，我们讲过除了ASP.NETCore自带的IOC容器外，如何使用Autofac来接管IServiceProvider进行依赖注入。

07

ASP.NET Core 6框架揭秘实例演示[05]：依赖注入基本编程模式

毫不夸张地说，整个ASP.NET Core就是建立在依赖注入框架之上的。ASP.NET Core应用在启动时构建管道所需的服务，以及管道处理请求使用到的服务，均来源于依赖注入容器。依赖注入容器不仅为ASP.NET Core框架自身提供必要的服务，还为应用程序提供服务，依赖注入已经成为ASP.NET Core应用的基本编程模式。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》）

03

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

毫不夸张地说，整个ASP.NET Core框架是建立在依赖注入框架之上的。ASP.NET Core应用在启动时构建管道以及利用该管道处理每个请求过程中使用到的服务对象均来源于依赖注入容器。该依赖注入容器不仅为ASP.NET Core框架自身提供必要的服务，同时也是应用程序的服务提供者，依赖注入已经成为了ASP.NET Core应用的基本编程模式。

03

学习ASP.NET Core, 怎能不了解请求处理管道[6]: 管道是如何随着WebHost的开启被构建出来的？

注册的服务器和中间件共同构成了ASP.NET Core用于处理请求的管道，这样一个管道是在我们启动作为应用宿主的WebHost时构建出来的。要深刻了解这个管道是如何被构建出来的，我们就必须对WebHost和它的创建者WebHostBuilder这个重要的对象具有深刻的理解。[本文已经同步到《ASP.NET Core框架揭秘》之中] 目录一、WebHost WebHostOptions 构建管道的三个步骤二、WebHostBuilder WebHost的创建几个常用的

08

ASP.NET Core 2.0 : 六. 举个例子来聊聊它的依赖注入

本文通过一个维修工与工具库的例子形象的描述一下为什么要用依赖注入、它的工作原理是什么样的, 然后根据这个类比一下ASP.NET Core 中的依赖注入, 从而深刻了解它的使用方法、注意事项以及回收机制等. ASP.NET Core 系列目录本文主要内容: 1.为什么要用依赖注入(DI) 2.容器的构建和规则 3.ASP.NET Core 2.0中的依赖注入 4.使用方法及需要注意的问题 5.服务的Dispose 6.我想换个容器 1.为什么要用依赖注入(DI) 什么是依赖注入就不说了, 为什么

03

ASP.NET Core应用基本编程模式[2]：依赖注入

基于IHostBuilder/IHost的服务承载系统建立在依赖注入框架之上，它在服务承载过程中依赖的服务（包括作为宿主的IHost对象）都由代表依赖注入容器的IServiceProvider对象提供。在定义承载服务时，也可以采用依赖注入方式来消费它所依赖的服务。作为依赖注入容器的IServiceProvider对象能否提供我们需要的服务实例，取决于相应的服务注册是否预先添加到依赖注入框架中。服务注册可以通过调用IHostBuilder接口或者IWebHostBuilder接口相应的方法来完成，前者在《服务承载系统》已经有详细介绍，下面介绍基于IWebHostBuilder接口的服务注册。[本文节选自《ASP.NET Core 3框架揭秘》第11章, 更多关于ASP.NET Core的文章请点这里]

04

[ASP.NET Core 3框架揭秘] 依赖注入[8]：服务实例的生命周期

生命周期决定了IServiceProvider对象采用怎样的方式提供和释放服务实例。虽然不同版本的依赖注入框架针对服务实例的生命周期管理采用了不同的实现，但总的来说原理还是类似的。在我们提供的依赖注入框架Cat中，我们已经模拟了三种生命周期模式的实现原理，接下来我们结合“服务范围”的概念来对这个话题做进一步讲述。

05

【ASP.NET Core 基础知识】--依赖注入（DI）--在ASP.NET Core中使用依赖注入

在ASP.NET Core中实现依赖注入的第一步是配置依赖注入。ASP.NET Core使用了一个称为依赖注入容器（DI Container）的组件来管理对象之间的依赖关系。DI容器在应用程序启动时被配置，并且可以在应用程序的整个生命周期内使用。以下是配置依赖注入的基本步骤：

00

ASP.NET Core路由中间件[3]: 终结点（Endpoint）

到目前为止，ASP.NET Core提供了两种不同的路由解决方案。传统的路由系统以IRouter对象为核心，我们姑且将其称为IRouter路由。本章介绍的是最早发布于ASP.NET Core 2.2中的新路由系统，由于它采用基于终结点映射的策略，所以我们将其称为终结点路由。终结点路由自然以终结点为核心，所以先介绍终结点在路由系统中的表现形式。[更多关于ASP.NET Core的文章请点这里]

01

ASP.NET Core真实管道详解[1]：中间件是个什么东西？

ASP.NET Core管道虽然在结构组成上显得非常简单，但是在具体实现上却涉及到太多的对象，所以我们在《ASP.NET Core管道深度剖析[共4篇]》中围绕着一个经过极度简化的模拟管道讲述了真实管道构建的方式以及处理HTTP请求的流程。在这个系列中，我们会还原构建模拟管道时刻意舍弃和改写的部分，想读者朋友们呈现一个真是的HTTP请求处理管道。 ASP.NET Core 的请求处理管道由一个Server和一组有序排列的中间件构成，前者仅仅完成基本的请求监听、接收和响应的工作，请求接收之后和响应之前

巧用 Lazy 解决.NET Core中的循环依赖关系

在构建应用程序时，良好的设计应该应避免服务之间的循环依赖, 循环依赖是指某些组件直接或间接相互依赖，比如下面这样

01

ASP.NET Core 2.0 : 六. 举个例子来聊聊它的依赖注入

本文通过一个维修工与工具库的例子形象的描述一下为什么要用依赖注入、它的工作原理是什么样的, 然后根据这个类比一下ASP.NET Core 中的依赖注入, 从而深刻了解它的使用方法、注意事项以及回收机制

05

[ASP.NET Core 3框架揭秘] 依赖注入[9]：实现概述

《服务注册》、《服务消费》和《生命周期》主要从实现原理的角度对.NET Core的依赖注入框架进行了介绍，接下来更进一步，看看该框架的总体设计和实现。在过去的多个版本更迭过程中，依赖注入框架的底层实现一直都在发生改变，加上底层的涉及的大都是内容接口和类型，所以我们不打算涉及太过细节的层面。

03

[ASP.NET Core 3框架揭秘] 异步线程无法使用IServiceProvider？

我们通过一个简单的实例来模拟该同事遇到的问题。我们采用极简的方式创建了如下这个ASP.NET Core MVC应用。如下面的代码片段所示，除了注册与ASP.NET Core MVC框架相关的服务与中间件之外，我们还调用了IHostBuilder的UseDefaultServiceProvider方法将配置选项ServiceProviderOptions的ValidateScopes属性设置为True，以开启针对服务范围的验证。我们还采用Scoped生命周期模式注册了服务IFoobar，具体的实现类型Foobar还实现了IDisposable接口。

04

探索 .NET Core 依赖注入的 IServiceProvider

在上一篇文章中，我们学习了Microsoft.Extensions.DependencyInjection中的IServiceCollection，包括服务注册转换为ServiceDescriptors，然后添加到集合中。

02

FeatureCollection

ASP.NET Core管道虽然在结构组成上显得非常简单，但是在具体实现上却涉及到太多的对象，所以我们在 “通过重建Hosting系统理解HTTP请求在ASP.NET Core管道中的处理流程”（上篇、中篇、下篇）中围绕着一个经过极度简化的模拟管道讲述了真实管道构建的方式以及处理HTTP请求的流程。在本系列中，我们会还原构建模拟管道时可以舍弃和改写的部分，向读者朋友们呈现一个真是的HTTP请求处理管道。 ASP.NET Core 的请求处理管道由一个服务器与一组有序排列的中间件构成，前者仅仅完成请求监听、接收和响应这些与底层网络相关的工作，至于请求接收之后和响应之前的所有工作都交给中间件来完成。ASP.NET Core的中间件通过一个类型Func<RequestDelegate, RequestDelegate>的委托对象来表示，而RequestDelegate也是一个委托，它代表一项请求处理任务。 [本文已经同步到《ASP.NET Core框架揭秘》之中]

02

.net core HttpClient 使用之消息管道解析（二）

前面分享了 .net core HttpClient 使用之掉坑解析（一），今天来分享自定义消息处理HttpMessageHandler和PrimaryHttpMessageHandler 的使用场景和区别

01

[ASP.NET Core 3框架揭秘] 依赖注入[10]：与第三方依赖注入框架的适配

.NET Core具有一个承载（Hosting）系统，承载需要在后台长时间运行的服务，一个ASP.NET Core应用仅仅是该系统承载的一种服务而已。承载系统总是采用依赖注入的方式来消费它在服务承载过程所需的服务。对于承载系统来说，原始的服务注册总是体现为一个IServiceCollection集合，最终的依赖注入容器则体现为一个IServiceProvider对象，如果要将第三方依赖注入框架整合进来，就需要利用它们解决从IServiceCollection集合到IServiceProvider对象之间的适配问题。

02

Dora.Interception，为.NET Core度身打造的AOP框架 [3]：多样化拦截器应用方式

在《以约定的方式定义拦截器》中，我们通过对拦截器的介绍了Dora.Interception的两种拦截机制，即针对接口的“实例拦截”针对虚方法的“类型拦截”。我们介绍了拦截器的本质以及基于约定的拦截器定义方式，接下来我们将着重关注拦截器的应用问题。

05

【半译】在ASP.NET Core中创建内部使用作用域服务的Quartz.NET宿主服务

在我的上一篇文章中，我展示了如何使用ASP.NET Core创建Quartz.NET托管服务并使用它来按计划运行后台任务。不幸的是，由于Quartz.NET API的工作方式，在Quartz作业中使用Scoped依赖项注入服务有些麻烦。说明下这篇文章部分采用机翻。

01

在ASP.NET Core中创建基于Quartz.NET托管服务轻松实现作业调度

在这篇文章中，我将介绍如何使用ASP.NET Core托管服务运行Quartz.NET作业。这样的好处是我们可以在应用程序启动和停止时很方便的来控制我们的Job的运行状态。接下来我将演示如何创建一个简单的 IJob，一个自定义的 IJobFactory和一个在应用程序运行时就开始运行的QuartzHostedService。我还将介绍一些需要注意的问题，即在单例类中使用作用域服务。

02

依赖注入[8]: .NET Core DI框架[服务消费]

包含服务注册信息的IServiceCollection对象最终被用来创建作为DI容器的IServiceProvider对象。当需要消费某个服务实例的时候，我们只需要指定服务类型调用IServiceProvider的GetService方法，IServiceProvider就会根据对应的服务注册提供所需的服务实例。

03

依赖注入[6]: .NET Core DI框架[编程体验]

毫不夸张地说，整个ASP.NET Core框架是建立在一个依赖注入框架之上的，它在应用启动时构建请求处理管道过程中，以及利用该管道处理每个请求过程中使用到的服务对象均来源于DI容器。该DI容器不仅为ASP.NET Core框架提供必要的服务，同时作为了应用的服务提供者，依赖注入已经成为了ASP.NET Core应用基本的编程模式。在前面一系列的文章中，我们主要从理论层面讲述了依赖注入这种设计模式，补充必要的理论基础是为了能够理解与ASP.NET Core框架无缝集成的依赖注入框架的设计原理。我们总是采用“先简单体验，后者深入剖析”来讲述每一个知识点，所以我们利用一些简单的实例从编程层面来体验一下服务注册的添加和服务实例的提取。

02

dotNET Core 3.X 依赖注入

如果说在之前的 dotNET 版本中，依赖注入还是个比较新鲜的东西，那么在 dotNET Core 中已经是随处可见了，可以说整个 dotNET Core 的框架是构建在依赖注入框架之上。本文说说对 dotNET Core 中依赖注入的理解。

03

从EFCore上下文的使用到深入剖析DI的生命周期最后实现自动属性注入

最近在把自己的一个老项目从Framework迁移到.Net Core 3.0，数据访问这块选择的是EFCore+Mysql。使用EF的话不可避免要和DbContext打交道，在Core中的常规用法一般是：创建一个XXXContext类继承自DbContext，实现一个拥有DbContextOptions参数的构造器，在启动类StartUp中的ConfigureServices方法里调用IServiceCollection的扩展方法AddDbContext，把上下文注入到DI容器中，然后在使用的地方通过构造函数的参数获取实例。OK，没任何毛病，官方示例也都是这么来用的。但是，通过构造函数这种方式来获取上下文实例其实很不方便，比如在Attribute或者静态类中，又或者是系统启动时初始化一些数据，更多的是如下一种场景：

02

[ASP.NET Core 3框架揭秘]服务承载系统[6]: 承载服务启动流程[下篇]

实际上HostBuilder对象并没有在实现的Build方法中调用构造函数来创建Host对象，该对象利用作为依赖注入容器的IServiceProvider对象创建的。为了可以采用依赖注入框架来提供构建的Host对象，HostBuilder必须完成前期的服务注册工作。总地来说，HostBuilder针对Host对象的构建大体可以划分为如下5个步骤：

06

ASP.NET Core中如影随形的”依赖注入”[上]: 从两个不同的ServiceProvider说起

我们一致在说 ASP.NET Core广泛地使用到了依赖注入，通过前面两个系列的介绍，相信读者朋友已经体会到了这一点。由于前面两章已经涵盖了依赖注入在管道构建过程中以及管道在处理请求过程的应用，但是内容相对分散和零碎，我们有必要针对这个主题作一个归纳性的介绍。采用依赖注入的服务均由某个ServiceProvider来提供，但是在ASP.NET Core管道涉及到两个不同的ServiceProvider，其中一个是在管道成功构建后创建并绑定到WebHost上的ServiceProvider，对应着WebHos

08

Core官方DI解析(2)-ServiceProvider

ServiceProvider是我们用来获取服务实例对象的类型,它也是一个特别简单的类型,因为这个类型本身并没有做什么,其实以一种代理模式,其核心功能全部都在IServiceProviderEngine实现类中

02

WPF 依赖注入之 Microsoft.Extensions.DependencyInjection

代码地址：https://gitee.com/dlgcy/DLGCY_WPFPractice/tree/Blog20230108

01

KestrelServer详解[3]: 自定义一个迷你版的KestrelServer

和所有的服务器一样，KestrelServer最终需要解决的是网络传输的问题。在《网络连接的创建》，我们介绍了KestrelServer如何利用连接接听器的建立网络连接，并再次基础上演示了如何直接利用建立的连接接收请求和回复响应。本篇更进一步，我们根据其总体设计，定义了迷你版的KestrelServer让读者看看这个重要的服务器大体是如何实现的。本文提供的示例演示已经同步到《ASP.NET Core 6框架揭秘-实例演示版》）

01

依赖注入[5]: 创建一个简易版的DI框架[下篇]

为了让读者朋友们能够对.NET Core DI框架的实现原理具有一个深刻而认识，我们采用与之类似的设计构架了一个名为Cat的DI框架。在《依赖注入[4]: 创建一个简易版的DI框架[上篇]》中我们介绍了Cat的基本编程模式，接下来我们就来聊聊Cat的设计和实现。

04

[ASP.NET Core 3框架揭秘] 依赖注入[7]：服务消费

包含服务注册信息的IServiceCollection集合最终被用来创建作为依赖注入容器的IServiceProvider对象。当需要消费某个服务实例的时候，我们只需要指定服务类型调用IServiceProvider的GetService方法即可，IServiceProvider对象就会根据对应的服务注册提供所需的服务实例。

03

Core官方DI解析(2)-ServiceProvider

ServiceProvider是我们用来获取服务实例对象的类型,它也是一个特别简单的类型,因为这个类型本身并没有做什么,其实以一种代理模式,其核心功能全部都在IServiceProviderEngine实现类中

04

[ASP.NET Core 3框架揭秘] 依赖注入[6]：服务注册

通过《利用容器提供服务》我们知道作为依赖注入容器的IServiceProvider对象是通过调用IServiceCollection接口的扩展方法BuildServiceProvider创建的，IServiceCollection对象是一个存放服务注册信息的集合。在《一个迷你版DI框架》中创建的Cat框架中的服务注册是通过类型ServiceRegistry表示的，在.NET Core依赖注入框架中，与之对应的类型是ServiceDescriptor。

03

ASP.NET Core中如影随形的”依赖注入”[下]: 历数依赖注入的N种玩法

在对ASP.NET Core管道中关于依赖注入的两个核心对象（ServiceCollection和ServiceProvider）有了足够的认识之后，我们将关注的目光转移到编程层面。在ASP.NET Core应用中基于依赖注入的编程主要涉及到两个方面，它们分别是将服务注册到ServiceCollection中，和采用注入的方式利用ServiceProvider提供我们所需的服务。我们先来讨论ASP.NET Core应用中如何进行服务注册。[本文已经同步到《ASP.NET Core框架揭秘》之中] 目录一

ASP.NET Core中的依赖注入（3）: 服务的注册与提供

在采用了依赖注入的应用中，我们总是直接利用DI容器直接获取所需的服务实例，换句话说，DI容器起到了一个服务提供者的角色，它能够根据我们提供的服务描述信息提供一个可用的服务对象。ASP.NET Core中的DI容器体现为一个实现了IServiceProvider接口的对象。 ServiceProvider与ServiceDescriptor 服务的注册与提供利用ServiceProvider来提供服务提供一个服务实例的集合获取ServiceProvider自身对象对

07

全新升级的AOP框架Dora.Interception[6]: 框架设计和实现原理

本系列前面的五篇文章主要介绍Dora.Interception（github地址，觉得不错不妨给一颗星）的编程模式以及对它的扩展定制，现在我们来聊聊它的设计和实现原理。

04

Core官方DI解析(5)-ServiceProviderEngine

最后来看看前面一直说的Engine(工作引擎)，工作引擎接口是IServiceProviderEngine在ServiceProvider的构造函数中看到了根据指定的Mode创建了不同的实现类,下面先来看一下IServiceProviderEngine接口和其实现类的整体结构

03

【5min+】设计模式的迷惑？Provider vs Factory

【五分钟的dotnet】是一个利用您的碎片化时间来学习和丰富.net知识的博文系列。它所包含了.net体系中可能会涉及到的方方面面，比如C#的小细节，AspnetCore，微服务中的.net知识等等。 5min+不是超过5分钟的意思，"+"是知识的增加。so，它是让您花费5分钟以下的时间来提升您的知识储备量。

02

Core官方DI解析(5)-ServiceProviderEngine

最后来看看前面一直说的Engine(工作引擎)，工作引擎接口是IServiceProviderEngine在ServiceProvider的构造函数中看到了根据指定的Mode创建了不同的实现类,下面先来看一下IServiceProviderEngine接口和其实现类的整体结构

05

全面理解 ASP.NET Core 依赖注入

DI在.NET Core里面被提到了一个非常重要的位置，这篇文章主要再给大家普及一下关于依赖注入的概念，身边有工作六七年的同事还个东西搞不清楚。另外再介绍一下.NET Core的DI实现以及对实例生命周期的管理（这个是经常面试会问到的问题）。最后再给大家简单介绍一下在控制台以及Mvc下如何使用DI，以及如何把默认的Service Container 替换成Autofac。我录了一些关于ASP.NET Core的入门视频：有兴趣的同学可以去看看。 http://www.cnblogs.com/jesse

08

ASP.NET Core 6框架揭秘实例演示[06]：依赖注入框架设计细节

由于依赖注入具有举足轻重的作用，所以《ASP.NET Core 6框架揭秘》的绝大部分章节都会涉及这一主题。本书第3章对.NET原生的依赖注入框架的设计和实现进行了系统的介绍，其中设计一些“鲜为人知”的细节，其中一部分就体现在本篇提供的这几个实例演示上。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》）

01

理解ASP.NET Core 依赖注入

Output类需要Rely类来帮助它实现输出的功能，这样Output类对Rely类产生了依赖，可以理解为Output依赖于Rely

03

ASP.NET Core+Quartz.Net实现web定时任务

作为一枚后端程序狗，项目实践常遇到定时任务的工作，最容易想到的的思路就是利用Windows计划任务/wndows service程序/Crontab程序等主机方法在主机上部署定时任务程序/脚本。

03

ASP.NET Core管道详解[2]: HttpContext本质论

ASP.NET Core请求处理管道由一个服务器和一组有序排列的中间件构成，所有中间件针对请求的处理都在通过HttpContext对象表示的上下文中进行。由于应用程序总是利用服务器来完成对请求的接收和响应工作，所以原始请求上下文的描述由注册的服务器类型来决定。但是ASP.NET Core需要在上层提供具有一致性的编程模型，所以我们需要一个抽象的、不依赖具体服务器类型的请求上下文描述，这就是本章着重介绍的HttpContext。[本文节选自《ASP.NET Core 3框架揭秘》第13章, 更多关于ASP.NET Core的文章请点这里]

03

Dora.Interception，为.NET Core度身打造的AOP框架 [4]：与依赖注入框架的无缝集成

Dora.Interception最初的定位就是专门针对.NET Core的AOP框架，所以在整个迭代过程中我大部分是在做减法。对于.NET Core程序开发来说，依赖注入已经成为无处不在并且“深入骨髓”的东西，不论是在进行业务应用的开发，还是进行基础组件的开发，依赖注入是实现“松耦合”最为理想的方式（没有之一）。对于绝大部分AOP框架来说，它们最终都会体现为创建一个能够拦截的“代理对象”来实现对方法调用的拦截，但是.NET Core中针对服务实例的提供完全由通过IServiceProvider接口表示的DI容器来接管，所以Dora.Interception必须将两者无缝地集成在一起。与依赖注入框架的集成不仅仅体现在对可被拦截的代理对象的创建，同样应用在了针对拦截器的定义和注册上。

03

扫码

添加站长进交流群

领取专属 10元无门槛券

手把手带您无忧上云

扫码加入开发者社群

相关资讯

热门标签

活动推荐

运营活动

活动名称

广告关闭