分享翻译一篇Abp框架作者(Halil İbrahim Kalkan)关于ASP.NET Core依赖注入的博文.
在本文中,我将分享我在ASP.NET Core应用程序中使用依赖注入的经验和建议.
这些原则背后的目的是:
有效地设计服务及其依赖关系
防止多线程问题
防止内存泄漏
防止潜在的错误
本文假设你已经熟悉基本的ASP.NET Core以及依赖注入. 如果没有的话,请首先阅读ASP.NET核心依赖注入文档.
ASP.NET Core 依赖注入文档
构造函数注入
构造函数注入用在服务的构造函数上声明和获取依赖服务.
例如：
public class ProductService{ private readonly IProductRepository _productRepository;
public ProductService(IProductRepository productRepository) {
_productRepository = productRepository;
}
public void Delete(int id) {
_productRepository.Delete(id);
}
}ProductService在构造函数中将IProductRepository注入为依赖项,然后在Delete方法中使用它.
属性注入
ASP.NET Core的标准依赖注入容器不支持属性注入,但是你可以使用其它支持属性注入的IOC容器.
例如：
using Microsoft.Extensions.Logging;using Microsoft.Extensions.Logging.Abstractions;namespace MyApp{ public class ProductService
{ public ILogger<ProductService> Logger { get; set; } private readonly IProductRepository _productRepository;
public ProductService(IProductRepository productRepository) {
_productRepository = productRepository;
Logger = NullLogger<ProductService>.Instance;
}
public void Delete(int id) {
_productRepository.Delete(id);
Logger.LogInformation(
$"Deleted a product with id = {id}");
}
}
}ProductService具有公开的Logger属性. 依赖注入容器可以自动设置Logger（前提是ILogger之前注册到DI容器中）.
建议做法
仅对可选依赖项使用属性注入。这意味着你的服务可以脱离这些依赖能正常工作.
尽可能得使用Null对象模式(如本例所示
Logger = NullLogger<ProductService>.Instance;), 不然就需要在使用依赖项时始终做空引用的检查.
服务定位器
服务定位器模式是获取依赖服务的另一种方式.
例如:
public class ProductService{ private readonly IProductRepository _productRepository; private readonly ILogger<ProductService> _logger;
public ProductService(IServiceProvider serviceProvider) {
_productRepository = serviceProvider
.GetRequiredService<IProductRepository>();
_logger = serviceProvider
.GetService<ILogger<ProductService>>() ??
NullLogger<ProductService>.Instance;
}
public void Delete(int id) {
_productRepository.Delete(id);
_logger.LogInformation($"Deleted a product with id = {id}");
}
}ProductService服务注入IServiceProvider并使用它来解析其依赖,如果欲解析的依赖未注册GetRequiredService会抛出异常,GetService只返回NULL.
在构造函数中解析的依赖,它们将会在服务被释放的时候释放,因此你不需要关心在构造函数中解析的服务释放/处置(release/dispose),这点同样适用于构造函数注入和属性注入.
建议做法
如果在开发过程中已知依赖的服务尽可能不使用服务定位器模式, 因为它使依赖关系含糊不清,这意味着在创建服务实例时无法获得依赖关系,特别是在单元测试中需要模拟服务的依赖性尤为重要.
尽可能在构造函数中解析所有的依赖服务,在服务的方法中解析服务会使你的应用程序更加的复杂且容易出错.我将在下一节中介绍在服务方法中解析依赖服务
服务生命周期
ASP.NET Core下依赖注入中有三种服务生命周期：
Transient,每次注入或请求时都会创建转瞬即逝的服务.
Scoped,是按范围创建的,在Web应用程序中,每个Web请求都会创建一个新的独立服务范围.这意味着服务根据每个Web请求创建.
Singleton,每个DI容器创建一个单例服务,这通常意味着它们在每个应用程序只创建一次,然后用于整个应用程序生命周期.
DI容器自动跟踪所有已解析的服务,服务在其生命周期结束时被释放/处置(release/dispose)
如果服务具有依赖关系,则它们的依赖的服务也会自动释放/处置(release/dispose)
如果服务实现IDisposable接口,则在服务被释放时自动调用Dispose方法.
建议做法
尽可能将你的服务生命周期注册为Transient,因为设计Transient服务很简单,你通常不关心多线程和内存泄漏,该服务的寿命很短.
请谨慎使用Scoped生命周期的服务,因为如果你创建子服务作用域或从非Web应用程序使用这些服务,则可能会非常棘手.
小心使用Singleton生命周期的服务,这种情况你需要处理多线程和潜在的内存泄漏问题.
不要在Singleton生命周期的服务中依赖Transient或Scoped生命周期的服务.因为Transient生命周期的服务注入到Singleton生命周期的服务时变为单例实例,如果Transient生命周期的服务没有对此种情况特意设计过,则可能导致问题. ASP.NET Core默认DI容器会对这种情况抛出异常.
在服务方法中解析依赖服务
在某些情况下你可能需要在服务方法中解析其他服务.在这种情况下,请确保在使用后及时释放解析得服务,确保这一点的最佳方法是创建Scoped服务.
例如：
public class PriceCalculator{ private readonly IServiceProvider _serviceProvider;
public PriceCalculator(IServiceProvider serviceProvider) {
_serviceProvider = serviceProvider;
}
public float Calculate(Product product, int count,
Type taxStrategyServiceType) { using (var scope = _serviceProvider.CreateScope())
{ var taxStrategy = (ITaxStrategy)scope.ServiceProvider
.GetRequiredService(taxStrategyServiceType); var price = product.Price * count; return price + taxStrategy.CalculateTax(price);
}
}
}PriceCalculator在构造函数中注入IServiceProvider服务,并赋值给_serviceProvider属性. 然后在PriceCalculator的Calculate方法中使用它来创建子服务范围。 它使用scope.ServiceProvider来解析服务，而不是注入的_serviceProvider实例。 因此从范围中解析的所有服务都将在using语句的末尾自动释放/处置(release/dispose)
建议做法
如果要在方法体中解析服务,请始终创建子服务范围以确保正确的释放已解析的服务.
如果将IServiceProvider作为方法的参数，那么你可以直接从中解析服务而无需关心释放/处置(release/dispose). 创建/管理服务范围是调用方法的代码的责任. 遵循这一原则使你的代码更清晰.
不要引用解析到的服务,不然它可能会导致内存泄漏或者在你以后使用对象引用时可能访问已处置的(dispose)服务(除非服务是单例)
单例服务(Singleton Services)
单例服务通常用于保持应用程序状态. 缓存服务是应用程序状态的一个很好的例子.
例如:
public class FileService{ private readonly ConcurrentDictionary<string, byte[]> _cache;
public FileService() {
_cache = new ConcurrentDictionary<string, byte[]>();
}
public byte[] GetFileContent(string filePath)
{ return _cache.GetOrAdd(filePath, _ =>
{ return File.ReadAllBytes(filePath);
});
}
}FileService缓存文件内容以减少磁盘读取. 此服务应注册为Singleton,否则缓存将无法按预期工作.
建议做法
如果服务需要保持状态,则应以线程安全的方式访问该状态.因为所有请求同时使用相同的服务实例.我使用ConcurrentDictionary而不是Dictionary来确保线程安全.
不要在单例服务中使用Scoped生命周期或Transient生命周期的服务.因为临时服务可能不是设计为线程安全.如果必须使用它们那么在使用这些服务时请注意多线程问题(例如使用锁).
内存泄漏通常由单例服务引起.它们在应用程序结束前不会被释放/处置(release/dispose). 因此如果他们实例化的类(或注入)但不释放/处置(release/dispose).它们,它们也将留在内存中直到应用程序结束. 确保在正确的时间释放/处置(released/disposed)它们。 请参阅上面的在方法中的解析服务内容.
如果缓存数据(本示例中的文件内容),则应创建一种机制,以便在原始数据源更改时更新/使缓存的数据无效(当上面示例中磁盘上的缓存文件发生更改时).
范围服务(Scoped Services)
Scoped生命周期的服务乍一看似乎是存储每个Web请求数据的良好候选者.因为ASP.NET Core会为每个Web请求创建一个服务范围. 因此,如果你将服务注册为作用域则可以在Web请求期间共享该服务.
例如:
public class RequestItemsService{ private readonly Dictionary<string, object> _items;
public RequestItemsService() {
_items = new Dictionary<string, object>();
}
public void Set(string name, object value) {
_items[name] = value;
}
public object Get(string name) { return _items[name];
}
}如果将RequestItemsService注册为Scoped并将其注入两个不同的服务,则可以获取从另一个服务添加的项,因为它们将共享相同的RequestItemsService实例.这就是我们对Scoped生命周期服务的期望.
但是...事实可能并不总是那样. 如果你创建子服务范围并从子范围解析RequestItemsService,那么你将获得RequestItemsService的新实例,它将无法按预期工作.因此,作用域服务并不总是表示每个Web请求的实例。
你可能认为你没有犯这样一个明显的错误(在子范围内解析服务). 情况可能不那么简单. 如果你的服务之间存在大的依赖关系,则无法知道是否有人创建了子范围并解析了注入另一个服务的服务.最终注入了作用域服务.
建议做法
Scoped生命周期的服务可以被认为是在Web请求中由太多服务注入的优化.因此,所有这些服务将在同一Web请求期间使用该服务的单个实例.
Scoped生命周期的服务不需要设计为线程安全的. 因为它们通常应由单个Web请求/线程使用.但是...在这种情况下,你不应该在不同的线程之间共享Scoped生命周期服务!
如果你设计Scoped生命周期服务以在Web请求中的其他服务之间共享数据,请务必小心(如上所述). 你可以将每个Web请求数据存储在HttpContext中(注入IHttpContextAccessor以访问它),这是更安全的方式. HttpContext的生命周期不是作用域. 实际上它根本没有注册到DI(这就是为什么你不注入它，而是注入IHttpContextAccessor). HttpContextAccessor使用AsyncLocal实现在Web请求期间共享相同的HttpContext.
结论
依赖注入起初看起来很简单,但是如果你不遵循一些严格的原则,就会存在潜在的多线程和内存泄漏问题. 我根据自己在ASP.NET Boilerplate框架开发过程中的经验分享了一些很好的原则.
原文地址:ASP.NET Core Dependency Injection Best Practices, Tips & Tricks
随时随地看视频
