首页
学习
活动
专区
圈层
工具
发布
首页
学习
活动
专区
圈层
工具
MCP广场
社区首页 >专栏 >从小白到大神——.NET下理解注入服务的作用域概念

从小白到大神——.NET下理解注入服务的作用域概念

作者头像
郑子铭
发布于 2025-04-27 05:25:53
发布于 2025-04-27 05:25:53
20600
代码可运行
举报
运行总次数:0
代码可运行

引言

嘿,各位码农朋友们!今天我们要聊的话题是.NET中的依赖注入(Dependency Injection,简称DI)服务的作用域概念。别急着关掉页面,我知道你们中的一些人可能已经在心里默念:“又是依赖注入,老生常谈了吧!” 但别急,今天我们要用一种全新的视角来理解这个话题,保证让你从“小白”秒变“大神”。

1.依赖注入:从“小白”到“大神”的第一步

在这里插入图片描述
在这里插入图片描述

1.1 什么是依赖注入?

首先,让我们回顾一下依赖注入的基本概念。依赖注入是一种设计模式,它允许我们将对象的创建和依赖关系的管理从代码中分离出来。简单来说,就是让你的代码更加灵活、可测试和可维护。

在.NET中,依赖注入是通过IServiceProvider接口和ServiceCollection类来实现的。我们可以通过ServiceCollection来注册服务,然后通过IServiceProvider来获取这些服务的实例。

1.2 为什么需要依赖注入?

想象一下,你正在开发一个电商网站。你的购物车服务依赖于库存服务和支付服务。如果没有依赖注入,你可能会这样写代码:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public classShoppingCart
{
    privatereadonlyInventoryService _inventoryService;
    privatereadonlyPaymentService _paymentService;

    publicShoppingCart()
    {
        _inventoryService =newInventoryService();
        _paymentService =newPaymentService();
    }

    publicvoidCheckout()
    {
        // 检查库存
        _inventoryService.CheckStock();
        // 处理支付
        _paymentService.ProcessPayment();
    }
}

这段代码看起来没什么问题,但它有一个致命的缺点:ShoppingCart类直接依赖于InventoryService和PaymentService的具体实现。这意味着如果你想替换InventoryService或PaymentService的实现,或者想在单元测试中模拟这些服务,你将不得不修改ShoppingCart类的代码。

依赖注入就是为了解决这个问题而生的。通过依赖注入,我们可以将ShoppingCart类的依赖关系从代码中分离出来,让它们可以在运行时动态注入。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public classShoppingCart
{
    privatereadonlyIInventoryService _inventoryService;
    privatereadonlyIPaymentService _paymentService;

    publicShoppingCart(IInventoryService inventoryService,IPaymentService paymentService)
    {
        _inventoryService = inventoryService;
        _paymentService = paymentService;
    }

    publicvoidCheckout()
    {
        // 检查库存
        _inventoryService.CheckStock();
        // 处理支付
        _paymentService.ProcessPayment();
    }
}

现在,ShoppingCart类不再直接依赖于InventoryServicePaymentService的具体实现,而是依赖于它们的接口IInventoryServiceIPaymentService。这样,我们就可以在运行时动态注入不同的实现,而不需要修改ShoppingCart类的代码。

2.服务的作用域:从“小白”到“大神”的第二步

什么是服务的作用域?

在.NET中,服务的作用域决定了服务的生命周期和实例化方式。.NET提供了三种服务作用域:

  1. Singleton(单例):整个应用程序生命周期内只创建一个实例。
  2. Scoped(作用域):在每个请求或作用域内创建一个实例。
  3. Transient(瞬时):每次请求时都创建一个新的实例。

2.1 Singleton(单例)

单例服务在整个应用程序生命周期内只创建一个实例。这意味着无论你在哪里请求这个服务,你都会得到同一个实例。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
services.AddSingleton<IInventoryService, InventoryService>();

单例服务非常适合那些无状态的服务,或者那些需要在整个应用程序中共享状态的服务。例如,配置服务、日志服务等。

注意: 单例可以替换旧代码中的大部分的静态类。

2.2 Scoped(作用域)

作用域服务在每个请求或作用域内创建一个实例。这意味着在同一个请求或作用域内,你每次请求这个服务都会得到同一个实例,但在不同的请求或作用域内,你会得到不同的实例。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
services.AddScoped<IPaymentService, PaymentService>();

作用域服务非常适合那些需要在同一个请求或作用域内共享状态的服务。例如,数据库上下文、用户会话等。

2.3 Transient(瞬时)

瞬时服务每次请求时都创建一个新的实例。这意味着无论你在哪里请求这个服务,你都会得到一个新的实例。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
services.AddTransient<IEmailService, EmailService>();

瞬时服务非常适合那些无状态的服务,或者那些不需要共享状态的服务。例如,邮件服务、通知服务等。

3.进阶:理解服务作用域的实际应用

3.1 场景一:单例服务的陷阱

假设我们有一个单例服务CounterService,它用于计数:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public classCounterService
{
    privateint _count =;

    publicintIncrement()
    {
        return++_count;
    }
}
我们在Startup.cs中注册这个服务:
services.AddSingleton<CounterService>();

然后我们在控制器中使用这个服务:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public class HomeController : Controller
{
    private readonly CounterService _counterService;

    public HomeController(CounterService counterService)
    {
        _counterService = counterService;
    }

    public IActionResult Index()
    {
        ViewBag.Count = _counterService.Increment();
        return View();
    }
}

有啥问题吗?

看起来没什么问题,对吧?但是,如果我们有多个用户同时访问这个页面,会发生什么呢?由于CounterService是单例的,所有的用户都会共享同一个CounterService实例,这会导致计数器的值被多个用户同时修改,从而产生竞争条件。

3.2 场景二:作用域服务的优势

为了避免上述问题,我们可以将CounterService注册为作用域服务: 这样,每个请求都会有一个独立的CounterService实例,不同用户之间的计数器不会相互干扰。

3.3 场景三:瞬时服务的灵活性

假设我们有一个邮件服务EmailService,它用于发送邮件:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public classEmailService
{
    publicvoidSendEmail(string to,string subject,string body)
    {
        // 发送邮件的逻辑
    }
}


services.AddTransient<EmailService>();

我们在控制器中使用这个服务:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public classHomeController:Controller
{
    privatereadonlyEmailService _emailService;

    publicHomeController(EmailService emailService)
    {
        _emailService = emailService;
    }

    publicIActionResultSendWelcomeEmail()
    {
        _emailService.SendEmail("webmote@gmail.com","Welcome","Welcome to our website!");
        returnView();
    }
}

由于EmailService是瞬时的,每次请求时都会创建一个新的实例。这意味着我们可以在不同的请求中使用不同的EmailService实例,而不需要担心它们之间的状态冲突。

4.进阶:服务作用域的嵌套与生命周期管理

嵌套作用域 在.NET中,我们可以创建嵌套的作用域。嵌套作用域允许我们在一个请求或作用域内创建另一个独立的作用域。这在某些场景下非常有用,例如在处理后台任务或并行操作时。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
using (var scope = serviceProvider.CreateScope())
{
    var scopedService = scope.ServiceProvider.GetRequiredService<ScopedService>();
    // 使用scopedService
}

在这个例子中,我们创建了一个新的作用域,并在该作用域内获取了一个ScopedService实例。这个实例只在该作用域内有效,当作用域结束时,它会被自动释放。

生命周期管理 在.NET中,服务的生命周期由IServiceProvider管理。当我们注册服务时,我们可以指定服务的生命周期。IServiceProvider会根据服务的生命周期来管理服务的创建和释放。

  1. Singleton:服务实例在第一次请求时创建,并在应用程序关闭时释放。
  2. Scoped:服务实例在作用域开始时创建,并在作用域结束时释放。
  3. Transient:服务实例在每次请求时创建,并在请求结束时释放。

注意事项

避免单例服务依赖作用域服务:单例服务的生命周期比作用域服务长,如果单例服务依赖作用域服务,会导致作用域服务在单例服务中无法正确释放,从而引发内存泄漏。

避免作用域服务依赖瞬时服务:作用域服务的生命周期比瞬时服务长,如果作用域服务依赖瞬时服务,会导致瞬时服务在作用域服务中无法正确释放,从而引发内存泄漏。

避免循环依赖:循环依赖是指两个或多个服务相互依赖,导致无法正确解析服务实例。在.NET中,循环依赖会导致InvalidOperationException异常。

5.进阶:自定义服务作用域

在某些情况下,我们可能需要自定义服务的作用域。例如,我们可能希望某个服务在特定的条件下才创建实例,或者在特定的条件下才释放实例。

自定义服务工厂 我们可以使用AddSingletonAddScopedAddTransient方法的另一个重载来注册自定义服务工厂。自定义服务工厂允许我们控制服务的创建过程。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
services.AddScoped<IService>(serviceProvider =>
{
    // 自定义服务创建逻辑
    return new CustomService();
});

在这个例子中,我们使用了一个自定义的工厂方法来创建CustomService实例。这样,我们就可以在服务创建时执行一些自定义逻辑。

自定义服务释放 我们可以通过实现IDisposable接口来自定义服务的释放逻辑。当服务的作用域结束时,IServiceProvider会自动调用服务的Dispose方法。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public class CustomService : IDisposable
{
    public void Dispose()
    {
        // 自定义服务释放逻辑
    }
}

在这个例子中,我们实现了IDisposable接口,并在Dispose方法中定义了自定义的释放逻辑。当CustomService实例的作用域结束时,Dispose方法会被自动调用。

6.进阶:服务作用域与异步编程

在异步编程中,服务作用域的管理变得更加复杂。由于异步操作可能会跨越多个线程,我们需要确保在异步操作中正确管理服务的作用域。

异步作用域 在异步操作中,我们可以使用AsyncLocal<T>来管理服务的作用域。AsyncLocal<T>允许我们在异步操作中共享数据,而不需要担心线程切换导致的数据丢失

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public classAsyncScopeService
{
    privatestaticreadonlyAsyncLocal<IServiceProvider> _asyncLocal =newAsyncLocal<IServiceProvider>();

    publicstaticIServiceProvider Current
    {
        get=> _asyncLocal.Value;
        set=> _asyncLocal.Value =value;
    }
}

在这个例子中,我们使用AsyncLocal<IServiceProvider>来存储当前的作用域。这样,我们就可以在异步操作中访问当前的作用域,而不需要担心线程切换导致的作用域丢失。 异步服务释放 在异步操作中,我们需要确保服务在异步操作结束时正确释放。我们可以使用using语句来确保服务在异步操作结束时自动释放。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public async Task DoSomethingAsync()
{
    using (var scope = serviceProvider.CreateScope())
    {
        var scopedService = scope.ServiceProvider.GetRequiredService<ScopedService>();
        await scopedService.DoSomethingAsync();
    }
}

在这个例子中,我们使用using语句来创建一个新的作用域,并在异步操作结束时自动释放作用域。这样,我们就可以确保服务在异步操作结束时正确释放。

7 进阶:服务作用域与AOP(面向切面编程)

AOP(Aspect-Oriented Programming)是一种编程范式,它允许我们将横切关注点(如日志、事务、安全等)从业务逻辑中分离出来。在.NET中,我们可以使用依赖注入来实现AOP

AOP与服务作用域AOP中,我们通常会在方法执行前后执行一些横切逻辑。这些横切逻辑可能需要访问服务实例,因此我们需要确保在AOP中正确管理服务的作用域。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public classLoggingAspect:IInterceptor
{
    privatereadonlyILogger _logger;

    publicLoggingAspect(ILogger logger)
    {
        _logger = logger;
    }

    publicvoidIntercept(IInvocation invocation)
    {
        _logger.LogInformation($"Before {invocation.Method.Name}");
        invocation.Proceed();
        _logger.LogInformation($"After {invocation.Method.Name}");
    }
}

在这个例子中,我们实现了一个LoggingAspect,它会在方法执行前后记录日志。由于LoggingAspect依赖于ILogger服务,我们需要确保在AOP中正确管理ILogger服务的作用域。

AOP与服务作用域的管理AOP中,我们可以使用IServiceProvider来获取服务实例,并确保在AOP中正确管理服务的作用域。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
public classLoggingAspect:IInterceptor
{
    privatereadonlyIServiceProvider _serviceProvider;

    publicLoggingAspect(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    publicvoidIntercept(IInvocation invocation)
    {
        using(var scope = _serviceProvider.CreateScope())
        {
            var logger = scope.ServiceProvider.GetRequiredService<ILogger>();
            logger.LogInformation($"Before {invocation.Method.Name}");
            invocation.Proceed();
            logger.LogInformation($"After {invocation.Method.Name}");
        }
    }
}

在这个例子中,我们使用IServiceProvider来创建一个新的作用域,并在AOP中正确管理ILogger服务的作用域。这样,我们就可以确保在AOP中正确管理服务的作用域。

8.进阶:Scope 以及嵌套Scope

注意: .net core原生的作用域是没有作用域树/嵌套的概念的!

Scope的每个作用域都是一样的,他们均由根容器创建,一个父作用域创建了一个子作用域,如果父作用域释放了,并不影响子作用域的使用!

例如:

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
 public classScopeB{
     publicScopeB(ScopeA a)
     {
         A = a;
     }

     publicScopeA A {get;}
}
------------------------------------

var sc =newServiceCollection();
sc.AddScoped<ScopeA>();
sc.AddScoped<ScopeB>();
sc.AddScoped<ScopeC>();
var sp = sc.BuildServiceProvider();

IServiceScope scope2;
ScopeA a2;
using(var scope1 = sp.CreateScope())
{
    var a1 = scope1.ServiceProvider.GetService<ScopeA>();
    var b1 = scope1.ServiceProvider.GetService<ScopeB>();

    scope2 = sp.CreateScope();
    {
        a2 = scope2.ServiceProvider.GetService<ScopeA>();
        var b2 = scope2.ServiceProvider.GetService<ScopeB>();
        var scope3= sp.GetService<IServiceScopeFactory>().CreateScope();

        var same =object.ReferenceEquals(a1, a2);
        Console.WriteLine($"a1==a2? {same}");
        Console.WriteLine($"b1.A==a1? {object.ReferenceEquals(b1.A, a1)}");
        Console.WriteLine($"b1.A==b2.A? {object.ReferenceEquals(b1.A, b2.A)}");
    }

}
var a3 = scope2.ServiceProvider.GetService<ScopeA>();
Console.WriteLine($"a2==a3? {object.ReferenceEquals(a2,a3)}");

输出结果是,scope1结束释放了,scope2并没有自动释放。

代码语言:javascript
代码运行次数:0
运行
AI代码解释
复制
a1==a2? False
b1.A==a1? True
b1.A==b2.A? False
a2==a3? True

多个Scope 的关系类似如图所示。

在这里插入图片描述
在这里插入图片描述

这里有个问题,你来思考下!

如果一个注册为瞬时周期的类A, 需要使用Scope1内的类ScopeA,怎么设计她们的关系?

想到了吗? 这里有两个方案提供给你:

  1. 保持瞬态类A的创建来自于Scope1,那么其直接获取或注入的ScopeA ,就来自Scope1,那么我们可直接访问。
  2. 瞬态类A注入一个单例类B,这个单例类B维持一个可以访问Scope1IServiceScope实例, 通过访问Scope1ServiceProvider获取ScopeA, 那这个ScopeA既然来自Scope1范围,那么它既是我们要找的对象。
本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2025-04-27,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 DotNet NB 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
暂无评论
推荐阅读
编辑精选文章
换一批
【半译】在ASP.NET Core中创建内部使用作用域服务的Quartz.NET宿主服务
在我的上一篇文章中,我展示了如何使用ASP.NET Core创建Quartz.NET托管服务并使用它来按计划运行后台任务。不幸的是,由于Quartz.NET API的工作方式,在Quartz作业中使用Scoped依赖项注入服务有些麻烦。说明下这篇文章部分采用机翻。
依乐祝
2020/04/23
2.2K0
揭秘 .Net Core 中的 IServiceProvider
.NET Core中的IServiceProvider接口是依赖注入(DI)系统的核心部分。它定义了一种检索服务对象的机制,这些服务对象是由依赖注入容器管理的类型的实例。理解IServiceProvider的工作原理以及如何有效地使用它,对于构建模块化且易于维护的应用程序至关重要。
郑子铭
2025/01/11
3930
揭秘 .Net Core 中的 IServiceProvider
.Net Core IoC
Ioc—Inversion of Control,即控制反转,其是一种设计思想,而不是一种技术。再没有使用IoC之前,我们一般是通过new来实例化,从而创建一个对象。但是我们使用IoC之后,创建这个对象的控制权将由内部转换到外部,那么这个过程便可以理解为控制反转。也即 把对象转换成抽象对象的依赖。
Karl Du
2023/10/20
4140
.Net Core IoC
全面理解 ASP.NET Core 依赖注入
DI在.NET Core里面被提到了一个非常重要的位置, 这篇文章主要再给大家普及一下关于依赖注入的概念,身边有工作六七年的同事还个东西搞不清楚。另外再介绍一下.NET  Core的DI实现以及对实例生命周期的管理(这个是经常面试会问到的问题)。最后再给大家简单介绍一下在控制台以及Mvc下如何使用DI,以及如何把默认的Service Container 替换成Autofac。 我录了一些关于ASP.NET Core的入门视频:有兴趣的同学可以去看看。 http://www.cnblogs.com/jesse
用户1153966
2018/03/14
2.5K0
全面理解 ASP.NET Core 依赖注入
ASP.NET Core 依赖注入
一、什么是依赖注入(Denpendency Injection) 这也是个老身常谈的问题,到底依赖注入是什么? 为什么要用它? 初学者特别容易对控制反转IOC(Iversion of Control),DI等概念搞晕。 1.1依赖 当一个类需要另一个类协作来完成工作的时候就产生了依赖。比如我们在AccountController这个控制器需要完成和用户相关的注册、登录 等事情。其中的登录我们由EF结合Idnetity来完成,所以我们封装了一个EFLoginService。这里AccountControlle
牛嗷嗷
2018/03/30
2K0
ASP.NET Core 优雅的获取IServiceProvider
在 ASP.NET Core 中,IServiceProvider 是依赖注入的核心接口,用于解析服务实例。可以通过多种方式获取 IServiceProvider,但每种方式的适用场景和行为可能有所不同。下面将详细介绍几种常见的获取方式,并分析它们之间的区别。
郑子铭
2025/05/17
3340
ASP.NET Core 优雅的获取IServiceProvider
asp.net core之依赖注入
ASP.NET Core 支持依赖关系注入 (DI) 软件设计模式,这是一种在类及其依赖关系之间实现控制反转 (IoC) 的技术。 按照官方文档的描述: 依赖关系注入通过以下方式解决了这些问题:
饭勺oO
2023/10/18
5950
asp.net core之依赖注入
依赖注入[6]: .NET Core DI框架[编程体验]
毫不夸张地说,整个ASP.NET Core框架是建立在一个依赖注入框架之上的,它在应用启动时构建请求处理管道过程中,以及利用该管道处理每个请求过程中使用到的服务对象均来源于DI容器。该DI容器不仅为ASP.NET Core框架提供必要的服务,同时作为了应用的服务提供者,依赖注入已经成为了ASP.NET Core应用基本的编程模式。在前面一系列的文章中,我们主要从理论层面讲述了依赖注入这种设计模式,补充必要的理论基础是为了能够理解与ASP.NET Core框架无缝集成的依赖注入框架的设计原理。我们总是采用“先简单体验,后者深入剖析”来讲述每一个知识点,所以我们利用一些简单的实例从编程层面来体验一下服务注册的添加和服务实例的提取。
蒋金楠
2018/08/09
8870
依赖注入[6]: .NET Core DI框架[编程体验]
[ASP.NET Core 3框架揭秘] 依赖注入[9]:实现概述
《服务注册》、《服务消费》和《生命周期》主要从实现原理的角度对.NET Core的依赖注入框架进行了介绍,接下来更进一步,看看该框架的总体设计和实现。在过去的多个版本更迭过程中,依赖注入框架的底层实现一直都在发生改变,加上底层的涉及的大都是内容接口和类型,所以我们不打算涉及太过细节的层面。
蒋金楠
2019/11/15
6580
[ASP.NET Core 3框架揭秘] 依赖注入[9]:实现概述
[ASP.NET Core 3框架揭秘] 依赖注入[5]: 利用容器提供服务
毫不夸张地说,整个ASP.NET Core框架是建立在依赖注入框架之上的。ASP.NET Core应用在启动时构建管道以及利用该管道处理每个请求过程中使用到的服务对象均来源于依赖注入容器。该依赖注入容器不仅为ASP.NET Core框架自身提供必要的服务,同时也是应用程序的服务提供者,依赖注入已经成为了ASP.NET Core应用的基本编程模式。
蒋金楠
2019/11/12
8740
ASP.NET Core 6框架揭秘实例演示[05]:依赖注入基本编程模式
毫不夸张地说,整个ASP.NET Core就是建立在依赖注入框架之上的。ASP.NET Core应用在启动时构建管道所需的服务,以及管道处理请求使用到的服务,均来源于依赖注入容器。依赖注入容器不仅为ASP.NET Core框架自身提供必要的服务,还为应用程序提供服务,依赖注入已经成为ASP.NET Core应用的基本编程模式。(本篇提供的实例已经汇总到《ASP.NET Core 6框架揭秘-实例演示版》)
蒋金楠
2022/05/09
7640
ASP.NET Core 6框架揭秘实例演示[05]:依赖注入基本编程模式
.net 温故知新:【7】IOC控制反转,DI依赖注入
大部分应用程序都是这样编写的:编译时依赖关系顺着运行时执行的方向流动,从而生成一个直接依赖项关系图。 也就是说,如果类 A 调用类 B 的方法,类 B 调用 C 类的方法,则在编译时,类 A 将取决于类 B,而 B 类又取决于类 C
SpringSun
2022/09/23
6200
.net 温故知新:【7】IOC控制反转,DI依赖注入
.NET依赖注入IOC你了解吗?
依赖注入是一种设计模式和软件设计原则,用于实现 控制反转。它的核心思想是:将对象所依赖的其他对象的创建和管理职责从对象内部转移到外部容器或框架,从而降低代码的耦合度,提高可测试性、可维护性和灵活性。
MaybeHC
2025/07/22
1430
在 ASP.NET Core 中掌握依赖关系注入
依赖项注入 (DI) 是 ASP.NET Core 中的一项重要功能,使您能够以弯曲的方式管理依赖于每个不同的实用程序的部分。虽然许多开发人员了解基础知识,但卓越的 DI 策略可以广泛增强大型或复杂计划的能力。在本文中,我们将介绍一些高级技术。
郑子铭
2024/11/26
3970
在 ASP.NET Core 中掌握依赖关系注入
.NET Core开发实战(第6课:作用域与对象释放行为)--学习笔记(上)
对于实现 IDisposable 类的实例的对象,容器会负责对其生命周期进行管理,使用完毕之后,他会释放这些对象
郑子铭
2021/01/13
4470
ASP.NET Core 依赖注入基本用法
ASP.NET Core从框架层对依赖注入提供支持。也就是说,如果你不了解依赖注入,将很难适应 ASP.NET Core的开发模式。本文将介绍依赖注入的基本概念,并结合代码演示如何在 ASP.NET Core中使用依赖注入。
拓荒者IT
2019/09/24
2.3K0
ASP.NET Core 依赖注入基本用法
dotnet 通过依赖注入的 Scoped 给工作流注入相同的上下文信息
本文将来聊聊 Microsoft.Extensions.DependencyInjection 这个依赖注入框架的 Scoped 功能的一个应用,这个框架是默认 ASP.NET Core 的核心库将会默认被引用。而其他 .NET 的应用如 WPF 或 Xamarin 等也可以使用这个库。因此本文标题就是 dotnet 而不是具体哪个框架 在开发的时候,咱会有一些复杂的逻辑需要多个类合作进行执行,而在使用多个类进行执行的时候,就涉及到上下文信息的传递。例如最简单的追踪 Id 的值,假定在多个类组成的多个步骤里面,因为存在多线程调用的问题,咱在定位问题的时候需要在日志里面输出当前步骤所使用的追踪 Id 是哪个,这样就运行进行并行多次任务同时执行,同时日志不会乱
林德熙
2020/07/28
6050
dotnet 通过依赖注入的 Scoped 给工作流注入相同的上下文信息
精:理解和使用 .NET Core中依赖注入的作用域
作用域是 .NET Core 依赖注入 (DI) 中的一个关键概念。它决定了注入到应用程序中的服务的生命周期和可见性。理解作用域的工作原理可以帮助你更高效地管理资源,避免常见的陷阱,如内存泄漏和不必要的对象创建。本文将探讨什么是作用域、.NET Core 中可用的不同作用域类型,以及如何通过实际示例使用它们。
郑子铭
2024/12/05
3960
精:理解和使用 .NET Core中依赖注入的作用域
Asp.net Core依赖注入的3种服务生命周期模式说明
在 ASP.NET 中,依赖注入 (Dependency Injection, DI) 提供了三种常见的服务生命周期模式:Singleton、Transient 和 Scoped。这些模式决定了服务的实例何时被创建、何时被销毁以及它们在应用程序中的生命周期。
哇侠转转
2024/04/07
1.8K0
【ASP.NET Core 基础知识】--依赖注入(DI)--在ASP.NET Core中使用依赖注入
在ASP.NET Core中实现依赖注入的第一步是配置依赖注入。ASP.NET Core使用了一个称为依赖注入容器(DI Container)的组件来管理对象之间的依赖关系。DI容器在应用程序启动时被配置,并且可以在应用程序的整个生命周期内使用。以下是配置依赖注入的基本步骤:
喵叔
2024/05/24
1.2K0
推荐阅读
相关推荐
【半译】在ASP.NET Core中创建内部使用作用域服务的Quartz.NET宿主服务
更多 >
领券
一站式MCP教程库,解锁AI应用新玩法
涵盖代码开发、场景应用、自动测试全流程,助你从零构建专属AI助手
问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档