ASP.NET Core依赖注入最佳实践,提示技巧

分享翻译一篇Abp框架作者(Halil İbrahim Kalkan)关于ASP.NET Core依赖注入的博文.

640?wx_fmt=png

在本文中,我将分享我在ASP.NET Core应用程序中使用依赖注入的经验和建议.

这些原则背后的目的是:

  1. 有效地设计服务及其依赖关系

  2. 防止多线程问题

  3. 防止内存泄漏

  4. 防止潜在的错误

本文假设你已经熟悉基本的ASP.NET Core以及依赖注入. 如果没有的话,请首先阅读ASP.NET核心依赖注入文档.
ASP.NET Core 依赖注入文档

构造函数注入

构造函数注入用在服务的构造函数上声明和获取依赖服务.
例如:

640?wx_fmt=png

ProductService在构造函数中将IProductRepository注入为依赖项,然后在Delete方法中使用它.

属性注入

ASP.NET Core的标准依赖注入容器不支持属性注入,但是你可以使用其它支持属性注入的IOC容器.
例如:

640?wx_fmt=png

ProductService具有公开的Logger属性. 依赖注入容器可以自动设置Logger(前提是ILogger之前注册到DI容器中).

建议做法

  1. 仅对可选依赖项使用属性注入。这意味着你的服务可以脱离这些依赖能正常工作.

  2. 尽可能得使用Null对象模式(如本例所示Logger = NullLogger<ProductService>.Instance;), 不然就需要在使用依赖项时始终做空引用的检查.

服务定位器

服务定位器模式是获取依赖服务的另一种方式.
例如:

640?wx_fmt=png

ProductService服务注入IServiceProvider并使用它来解析其依赖,如果欲解析的依赖未注册GetRequiredService会抛出异常,GetService只返回NULL.

在构造函数中解析的依赖,它们将会在服务被释放的时候释放,因此你不需要关心在构造函数中解析的服务释放/处置(release/dispose),这点同样适用于构造函数注入和属性注入.

建议做法

  1. 如果在开发过程中已知依赖的服务尽可能不使用服务定位器模式, 因为它使依赖关系含糊不清,这意味着在创建服务实例时无法获得依赖关系,特别是在单元测试中需要模拟服务的依赖性尤为重要.

  2. 尽可能在构造函数中解析所有的依赖服务,在服务的方法中解析服务会使你的应用程序更加的复杂且容易出错.我将在下一节中介绍在服务方法中解析依赖服务

服务生命周期

ASP.NET Core下依赖注入中有三种服务生命周期:

  1. Transient,每次注入或请求时都会创建转瞬即逝的服务.

  2. Scoped,是按范围创建的,在Web应用程序中,每个Web请求都会创建一个新的独立服务范围.这意味着服务根据每个Web请求创建.

  3. Singleton,每个DI容器创建一个单例服务,这通常意味着它们在每个应用程序只创建一次,然后用于整个应用程序生命周期.

DI容器自动跟踪所有已解析的服务,服务在其生命周期结束时被释放/处置(release/dispose)

  1. 如果服务具有依赖关系,则它们的依赖的服务也会自动释放/处置(release/dispose)

  2. 如果服务实现IDisposable接口,则在服务被释放时自动调用Dispose方法.

建议做法

  1. 尽可能将你的服务生命周期注册为Transient,因为设计Transient服务很简单,你通常不关心多线程和内存泄漏,该服务的寿命很短.

  2. 请谨慎使用Scoped生命周期的服务,因为如果你创建子服务作用域或从非Web应用程序使用这些服务,则可能会非常棘手.

  3. 小心使用Singleton生命周期的服务,这种情况你需要处理多线程和潜在的内存泄漏问题.

  4. 不要在Singleton生命周期的服务中依赖TransientScoped生命周期的服务.因为Transient生命周期的服务注入到Singleton生命周期的服务时变为单例实例,如果Transient生命周期的服务没有对此种情况特意设计过,则可能导致问题. ASP.NET Core默认DI容器会对这种情况抛出异常.

在服务方法中解析依赖服务

在某些情况下你可能需要在服务方法中解析其他服务.在这种情况下,请确保在使用后及时释放解析得服务,确保这一点的最佳方法是创建Scoped服务.
例如:

640?wx_fmt=png

PriceCalculator在构造函数中注入IServiceProvider服务,并赋值给_serviceProvider属性. 然后在PriceCalculator的Calculate方法中使用它来创建子服务范围。 它使用scope.ServiceProvider来解析服务,而不是注入的_serviceProvider实例。 因此从范围中解析的所有服务都将在using语句的末尾自动释放/处置(release/dispose)

建议做法

  1. 如果要在方法体中解析服务,请始终创建子服务范围以确保正确的释放已解析的服务.

  2. 如果将IServiceProvider作为方法的参数,那么你可以直接从中解析服务而无需关心释放/处置(release/dispose). 创建/管理服务范围是调用方法的代码的责任. 遵循这一原则使你的代码更清晰.

  3. 不要引用解析到的服务,不然它可能会导致内存泄漏或者在你以后使用对象引用时可能访问已处置的(dispose)服务(除非服务是单例)

单例服务(Singleton Services)

单例服务通常用于保持应用程序状态. 缓存服务是应用程序状态的一个很好的例子.
例如:

640?wx_fmt=png

FileService缓存文件内容以减少磁盘读取. 此服务应注册为Singleton,否则缓存将无法按预期工作.

建议做法

  1. 如果服务需要保持状态,则应以线程安全的方式访问该状态.因为所有请求同时使用相同的服务实例.我使用ConcurrentDictionary而不是Dictionary来确保线程安全.

  2. 不要在单例服务中使用Scoped生命周期或Transient生命周期的服务.因为临时服务可能不是设计为线程安全.如果必须使用它们那么在使用这些服务时请注意多线程问题(例如使用锁).

  3. 内存泄漏通常由单例服务引起.它们在应用程序结束前不会被释放/处置(release/dispose). 因此如果他们实例化的类(或注入)但不释放/处置(release/dispose).它们,它们也将留在内存中直到应用程序结束. 确保在正确的时间释放/处置(released/disposed)它们。 请参阅上面的在方法中的解析服务内容.

  4. 如果缓存数据(本示例中的文件内容),则应创建一种机制,以便在原始数据源更改时更新/使缓存的数据无效(当上面示例中磁盘上的缓存文件发生更改时).

范围服务(Scoped Services)

Scoped生命周期的服务乍一看似乎是存储每个Web请求数据的良好候选者.因为ASP.NET Core会为每个Web请求创建一个服务范围. 因此,如果你将服务注册为作用域则可以在Web请求期间共享该服务.
例如:

640?wx_fmt=png

如果将RequestItemsService注册为Scoped并将其注入两个不同的服务,则可以获取从另一个服务添加的项,因为它们将共享相同的RequestItemsService实例.这就是我们对Scoped生命周期服务的期望.

但是...事实可能并不总是那样. 如果你创建子服务范围并从子范围解析RequestItemsService,那么你将获得RequestItemsService的新实例,它将无法按预期工作.因此,作用域服务并不总是表示每个Web请求的实例。

你可能认为你没有犯这样一个明显的错误(在子范围内解析服务). 情况可能不那么简单. 如果你的服务之间存在大的依赖关系,则无法知道是否有人创建了子范围并解析了注入另一个服务的服务.最终注入了作用域服务.

建议做法

  1. Scoped生命周期的服务可以被认为是在Web请求中由太多服务注入的优化.因此,所有这些服务将在同一Web请求期间使用该服务的单个实例.

  2. Scoped生命周期的服务不需要设计为线程安全的. 因为它们通常应由单个Web请求/线程使用.但是...在这种情况下,你不应该在不同的线程之间共享Scoped生命周期服务!

  3. 如果你设计Scoped生命周期服务以在Web请求中的其他服务之间共享数据,请务必小心(如上所述). 你可以将每个Web请求数据存储在HttpContext中(注入IHttpContextAccessor以访问它),这是更安全的方式. HttpContext的生命周期不是作用域. 实际上它根本没有注册到DI(这就是为什么你不注入它,而是注入IHttpContextAccessor). HttpContextAccessor使用AsyncLocal实现在Web请求期间共享相同的HttpContext.

结论

依赖注入起初看起来很简单,但是如果你不遵循一些严格的原则,就会存在潜在的多线程和内存泄漏问题. 我根据自己在ASP.NET Boilerplate框架开发过程中的经验分享了一些很好的原则.

相关文章:

  • C#中字段、属性、只读、构造函数赋值、反射赋值的相关

原文地址:https://www.cnblogs.com/realmaliming/p/9467601.html


.NET社区新闻,深度好文,欢迎访问公众号文章汇总 http://www.csharpkit.com 

640?wx_fmt=jpeg

本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如若转载,请注明出处:http://www.mzph.cn/news/320413.shtml

如若内容造成侵权/违法违规/事实不符,请联系多彩编程网进行投诉反馈email:809451989@qq.com,一经查实,立即删除!

相关文章

Maximize The Beautiful Value

传送 时间限制&#xff1a;C/C 2秒&#xff0c;其他语言4秒 空间限制&#xff1a;C/C 131072K&#xff0c;其他语言262144K 64bit IO Format:%lld 题目描述 Today HH finds a non-decreasing sequence(a1,a2…an,ai≤ai1), he thinks it’s not beautiful so he wants to make …

MEF 插件式开发 - DotNetCore 初体验

背景叙述在传统的基于 .Net Framework 框架下进行的 MEF 开发&#xff0c;大多是使用 MEF 1&#xff0c;对应的命名空间是 System.ComponentModel.Composition。在 DotNet Core 中&#xff0c;微软为了伟大的跨平台策略&#xff0c;引入了 MEF 2&#xff0c;其对应的命名空间是…

反向传播算法学习笔记

反向传播算法(Back propagation) 目的及思想 我们现在有一堆输入&#xff0c;我们希望能有一个网络&#xff0c;使得通过这个网络的构成的映射关系满足我们的期待。也就是说&#xff0c;我们在解决这个问题之前先假设&#xff0c;这种映射可以用网络的模型来比较好的描述。为什…

求树的直径

欢迎来踩本人博客 树的直径&#xff1a; 就是树上最长路 方法 &#xff1a; 求两边DFS即可 步骤&#xff1a; 1.从任意一点进行dfs&#xff0c;然后找到一个最长路径&#xff0c;记录最远点u 2.然后从u再进行dfs&#xff0c;找最长路径&#xff0c;记录一点v。 &#xff08;u&…

微软技术直通车(第三期) 之 人工智能

编者&#xff1a;有幸本周在北京&#xff0c;大家有空来现场面基。微软技术直通车本系列活动密切关注微软及周边相关技术。以微软云计算和相关产品为依托&#xff0c;涉及云计算、数据处理、开发工具、商用软件、物联网、人工智能等前沿科技。系列活动邀请微软技术专家、一线开…

Visual Studio 2017 15.8 正式发布,测试速度提高 82%

Visual Studio 2017 15.8 版本已正式发布&#xff1a;发行说明&#xff1a;https://docs.microsoft.com/zh-cn/visualstudio/releasenotes/vs2017-relnotes#15.8下载地址&#xff1a;https://visualstudio.microsoft.com/downloads/安装现可选择在开始安装之前下载所有安装文件…

.NET Core 2.1中的HttpClientFactory最佳实践

ASP.NET Core 2.1中出现一个新的HttpClientFactory功能&#xff0c;它有助于解决开发人员在使用HttpClient实例从其应用程序发出外部Web请求时可能遇到的一些常见问题。介绍在.NETCore平台的2.1新增了HttpClientFactory&#xff0c;虽然HttpClient这个类实现了disposable&#…

树学

文章目录题目描述题解1&#xff1a;代码:题解2&#xff1a;代码&#xff1a;传送时间限制&#xff1a;C/C 2秒&#xff0c;其他语言4秒 空间限制&#xff1a;C/C 262144K&#xff0c;其他语言524288K 64bit IO Format:> %lld 题目描述 牛妹有一张连通图&#xff0c;由n个点…

csp-2019 复赛游记

文章目录Day0Day\ 0Day 0Day1Day\ 1Day 1Day2Day\ 2Day 2总结:csp−J:csp-J:csp−J:csp−s:csp-s:csp−s:遥远的梦想&#xff1a;Day0Day\ 0Day 0 早上&#xff0c;在运动会上乱搞一波&#xff0c;然后在10点左右到了机房&#xff0c;然后发现巨佬几枚&#xff0c;远看似在认证…

Rainbond v3.7.0:实现企业级PaaS的稳定性

Rainbond v3.7.0&#xff1a;实现企业级PaaS的稳定性Rainbond在v3.7.0版本中释出了大量平台稳定性更新&#xff0c;并在应用管理功能、安全性和系统安装三方面进行了部分优化。作为IT基础系统平台&#xff0c;Rainbond从低耦合的架构设计、高可用的部署方式、自恢复与容错的设计…

简单多边形三角化(暴力)

简单多边形三角化(暴力) 说在前面 网上流传着各种神奇的多边形三角剖分算法&#xff0c;但是讲道理&#xff0c;实现难度太高了。。。也没有搜到其他人的实现。这里写个最暴力的做法。。随机数据验证没问题&#xff0c;欢迎 hack 实现 一个简单多边形的耳朵定义为&#xff1a;如…

牛客网【每日一题】4月13号 Accumulation Degree

文章目录题目描述样例分析&#xff1a;题意&#xff1a;题解&#xff1a;代码&#xff1a;本题目传送题目树学是这个题的简易版&#xff0c;也涉及换根问题&#xff0c;可以先看看这个 树学 时间限制&#xff1a;C/C 1秒&#xff0c;其他语言2秒 空间限制&#xff1a;C/C 32768…

微软把UWP定位成业务线应用程序开发平台

微软把UWP定位成传统业务线&#xff08;LOB&#xff09;应用程序开发平台&#xff0c;以使用Windows Template Studio实现快速应用程序开发为重点。但是&#xff0c;为了把LOB开发人员吸引到UWP平台&#xff0c;他们在做的事情不止这些。最初发布时&#xff0c;通用Windows平台…

读 《CSharp Coding Guidelines》有感

C# 编程指南前不久在 Github 上看见了一位大牛创建一个仓库&#xff1a;CSharpCodingGuidelines&#xff0c;打开之后看了一下 readme.md 相关描述&#xff0c;感觉应该很不错&#xff0c;于是就 clone 到本地拜读一下&#xff0c;这里列一些自己的笔记&#xff0c;方便日后回顾…

牛客网 【每日一题】4月10日 二分图染色(弱化版)

精讲 组合、容斥 文章目录题目&#xff1a;题意&&题解&#xff1a;&#xff1a;代码&#xff1a;题目传送题目&#xff1a; 时间限制&#xff1a;C/C 1秒&#xff0c;其他语言2秒 空间限制&#xff1a;C/C 524288K&#xff0c;其他语言1048576K 64bit IO Format: %lld …

微软Windows Community Toolkit一览

为了满足业务线开发人员的需求&#xff0c;微软推出了Windows Community Toolkit。这个快速变化的库充当了新的UWP控件和功能的测试基础。在创建UWP之初&#xff0c;其重点目标是智能手机和平板电脑。这意味着大部分开发预算都花费在控件上&#xff0c;确保这些控件能够在有限的…

如何简单的在 ASP.NET Core 中集成 JWT 认证?

前情提要&#xff1a;ASP.NET Core 使用 JWT 搭建分布式无状态身份验证系统文章超长预警&#xff08;1万字以上&#xff09;&#xff0c;不想看全部实现过程的同学可以直接跳转到末尾查看成果或者一键安装相关的 nuget 包自上一篇介绍如何在 ASP.NET Core 中集成 JWT 的博文发布…

【二分】【暴力】蛋糕(gmoj 3918)

蛋糕 gmoj 3918 题目大意&#xff1a; 有一个蛋糕&#xff0c;分成n∗mn*mn∗m个单位&#xff0c;现在横竖各切三刀&#xff0c;使其分成16个矩阵&#xff0c;使价值最小的矩阵价值最大 输出样例 5 5 95998 21945 23451 99798 74083输入样例 3数据范围 40%的数据&#x…

Music Problem

文章目录题目描述题意&#xff1a;题解&#xff1a;传送时间限制&#xff1a;C/C 2秒&#xff0c;其他语言4秒 空间限制&#xff1a;C/C 131072K&#xff0c;其他语言262144K 64bit IO Format: %lld 题目描述 Listening to the music is relax, but for obsessive(强迫症), it …

可扩展架构设计的三个维度

业界对于可扩展的系统架构设计有一个朴素的理念,就是&#xff1a;通过加机器就可以解决容量和可用性问题这一理念在“云计算”概念疯狂流行的今天&#xff0c;得到了广泛的认可&#xff01;对于一个规模迅速增长的系统而言&#xff0c;容量和性能问题当然是首当其冲的。但是随着…