在这篇文章，我将分享一些在ASP.NET Core程序中使用依赖注入的个人经验和建议。这些原则背后的动机如下：
- 高效地设计服务和它们的依赖。
- 预防多线程问题。
- 预防内存泄漏。
- 预防潜在的BUG。
这篇文章假设你已经基本熟悉依赖注入和ASP.NET Core。如果不是，则先阅读文章： 在ASP.NET Core中使用依赖注入
基础
构造函数注入
构造函数注入常用于在服务构建上定义和获取服务依赖。例如：
1 public class ProductService
2 {
3 private readonly IProductRepository _productRepository;
4 public ProductService(IProductRepository productRepository)
5 {
6 _productRepository = productRepository;
7 }
8 public void Delete(int id)
9 {
10 _productRepository.Delete(id);
11 }
12 }
ProductService 将 IProductRepository作为依赖注入到它的构造函数，然后在 Delete 方法内部使用这个依赖。
实践指南：
- 在服务构造函数中明确地定义必需的依赖。因此该服务在没有这些依赖时无法被构造。
- 将注入的依赖赋值给只读（readonly）的字段或属性(为了防止在内部方法中意外地赋予其他值)。
属性注入
ASP.NET Core 的标准依赖注入容器不支持属性注入。但是你可以使用其他容器支持属性注入。例如：
1 using Microsoft.Extensions.Logging;
2 using Microsoft.Extensions.Logging.Abstractions;
3 namespace MyApp
4 {
5 public class ProductService
6 {
7 public ILogger Logger { get; set; }
8 private readonly IProductRepository _productRepository;
9 public ProductService(IProductRepository productRepository)
10 {
11 _productRepository = productRepository;
12 Logger = NullLogger.Instance;
13 }
14 public void Delete(int id)
15 {
16 _productRepository.Delete(id);
17 Logger.LogInformation(
18 $"Deleted a product with id = {id}");
19 }
20 }
21 }
ProductService 定义了一个带公开setter的Logger 属性。
依赖注入容器可以设置 Logger属性，如果它可用（已经注册到DI容器）。
实践指南：
- 仅对可选依赖使用属性注入。这意味着你的服务可以在没有提供这些依赖时正常地工作。
- 如果可能，使用空对象模式（就像这个例子中这样）。否则，在使用这个依赖时始终检查是否为null
服务定位器
服务定位器模式是获取依赖关系的另外一种方式。例如：
1 public class ProductService
2 {
3 private readonly IProductRepository _productRepository;
4 private readonly ILogger _logger;
5 public ProductService(IServiceProvider serviceProvider)
6 {
7 _productRepository = serviceProvider
8 .GetRequiredService
9 _logger = serviceProvider
10 .GetService>() ??
11 NullLogger.Instance;
12 }
13 public void Delete(int id)
14 {
15 _productRepository.Delete(id);
16 _logger.LogInformation($"Deleted a product with id = {id}");
17 }
18 }
ProductService 注入了 IServiceProvider 来解析并使用依赖。 如果请求的依赖之前没有被注册，那么GetRequiredService将会抛出异常。换句话说， 这种情况下，GetService只会返回null。
当你在构造函数内部解析服务时，它们会随着服务的释放而释放。因此，你不必关心构造函数内部已解析服务的释放问题（就像构造函数注入和属性注入）。
实践指南
- 尽可能不要使用服务定位模式（除非服务类型在开发时就已经知道）。因为它让依赖不明确。这意味着在创建服务实例期间不可能容易地看出依赖关系。这对单元测试来说尤为重要，因为你可能想要模拟一些依赖。
- 如果可能，在服务构造函数中解析依赖。在服务方法中解析会使你的程序更加难懂、更加容易出错。我将在下一个章节讨论问题和解决方案。
服务生命周期
下面是服务在ASP.NET Core依赖注入中的生命周期：
- Transient 类型的服务在每次注入或请求的时候被创建。
- Scoped 类型的服务按照作用域被创建。在Web程序中，每个Web请求都会创建新的隔离的服务作用域。这意味着Scoped类型的服务通常会根据Web请求创建。
- Singleton 类型的服务由DI容器创建。这通常意味着它们根据应用程序仅仅被创建一次，然后用于应用程序的整个生命周期。
DI容器会持续跟踪所有已经被解析的服务。当服务的生命周期终止时，它们会被释放并销毁：
- 如果服务还有依赖，它们同样会被自动释放并销毁。
- 如果服务实现了 IDisposable 接口，Dispose 方法会在服务释放时自动被调用。
实践指南：
- 尽可能地将你的服务注册为 Transient 类型。因为设计Transient服务是简单的。你通常不用关心多线程问题和内存泄漏问题，并且你知道这类服务只有很短的生存期。
- 谨慎使用 Scoped 类型服务生命周期，因为如果你创建了子服务作用域或者由非Web程序使用这些服务，那么它会变得诡异复杂。
- 谨慎使用Singleton 类型的生命周期，因为你需要处理多线程问题和潜在的内存泄漏问题。
- 不要在Singleton服务上依赖 Transient类型或者 Scoped类型的服务。因为当单例服务注入的时候，Transient服务也会变成单例实例。并且如果Transient服务不是设计用于支持这样的场景的话则可能会导致一些问题。ASP.NET Core的默认DI容器在这种情况下会抛出异常。
在方法体中解析服务
在某些情况下，你可能需要在你的服务的某个方法中解析另一个服务。 这种情况下，请确保在使用后释放该服务。保障这个的最好方法是创建一个服务作用域。例如：
1 public class PriceCalculator 2 { 3 private readonly IServiceProvider _serviceProvider;
4 public PriceCalculator(IServiceProvider serviceProvider) 5 { 6 _serviceProvider = serviceProvider; 7 }
8 public float Calculate(Product product, int count, 9 Type taxStrategyServiceType) 10 { 11 using (var scope = _serviceProvider.CreateScope()) 12 { 13 var taxStrategy = (ITaxStrategy)scope.ServiceProvider 14 .GetRequiredService(taxStrategyServiceType);
15 var price = product.Price * count;
16 return price + taxStrategy.CalculateTax(price); 17 } 18 } 19 }
PriceCalculator 在构造函数中注入了 IServiceProvider，并赋值给了一个字段。然后，PriceCalculator使用它在 Calculate方法内部创建了一个子服务作用域。该作用域使用 scope.ServiceProvider来解析服务，替代了注入的 _serviceProvider 实例。因此，在using语句结束后，所有从该作用域解析的服务都会自动释放并销毁。
实践指南：
- 如果你在某个方法体内解析服务，始终创建一个子服务作用域来确保解析出的服务被正确地释放。
- 如果某个方法使用 IServiceProvider作为参数，你可以直接从它解析服务，并且不必关心服务的释放和销毁。创建和管理服务作用域是调用你方法的代码的职责。遵循这个原则可以使你的代码更加整洁。
- 不要让解析到的服务持有引用！否则，它可能导致内存泄漏。并且当你后面在使用对象引用时，你可能访问到一个已经销毁的服务。（除非解析到的服务是单例）
Singleton服务
单例服务通常设计用于保持应用程序状态。缓存是一个应用程序状态的好例子。例如：
1 public class FileService 2 { 3 private readonly ConcurrentDictionary<string, byte[]> _cache;
4 public FileService() 5 { 6 _cache = new ConcurrentDictionary<string, byte[]>(); 7 } 8 public byte[] GetFileContent(string filePath) 9 { 10 return _cache.GetOrAdd(filePath, _ => 11 { 12 return File.ReadAllBytes(filePath); 13 }); 14 } 15 }
FileService简单地缓存了文件内容以减少磁盘读取。这个服务应该被注册为一个单例，否则，缓存将无法按照预期工作。
实践指南：
- 如果服务持有状态，那它应该以线程安全的方式来访问这个状态。因为所有请求会并发地使用该服务的同一个实例。我使用 ConcurrentDictionary 替代 Dictionary 来确保线程安全。
- 不要在单例服务中使用Transient或Scoped服务。因为Transient服务可能不是设计为线程安全的。如果你使用了它们，在使用这些服务期间需要处理多线程问题（对实例使用lock语句）
- 内存泄漏通常由单例服务导致。在应用程序结束前单例服务不会被释放/销毁。因此，如果这些单例服务实例化了类（或注入）但是没有释放/销毁，这些类会一直保留在内存中，直到应用程序结束。确保适时地释放/销毁这些类。见上面“在方法体中解析服务”的章节。
- 如果你缓存数据（本例中的文件内容），当原始数据源发生变化时，你应该创建一个机制来更新/失效缓存的数据。
Scoped 服务
Scoped 生命周期的服务看起来是一个不错的存储每个Web请求数据的好方法。因为ASP.NET Core为每个Web请求创建一个服务作用域。因此，如果你把一个服务注册为Scoped，那么它可以在一个Web请求期间被共享。例如：
1 public class RequestItemsService 2 { 3 private readonly Dictionary<string, object> _items; 4 5 public RequestItemsService() 6 { 7 _items = new Dictionary<string, object>(); 8 } 9 10 public void Set(string name, object value) 11 { 12 _items[name] = value; 13 } 14 15 public object Get(string name) 16 { 17 return _items[name]; 18 } 19 }
如果你将RequestItemsService注册为Scoped，并注入到两个不同的服务，然后你可以得到一个从另外一个服务添加的项。因为它们会共享同一个RequestItemsService的实例。这就是我们对 Scoped服务的预期。
但是！！！事实并不总是如此。 如果你创建了一个子服务作用域并从子作用域解析RequestItemsService，然后你会得到一个RequestItemsService的新实例，并且不会按照你的预期工作。因此，Scoped服务并不总是意味着每个Web请求一个实例。
你可能认为你不会犯如此明显的错误（在子作用域内部解析另一个作用域）。但是，这并不是一个错误（一个很常规的用法）并且情况可能不会如此简单。如果你的服务之间有一个大的依赖关系，你不知道是否有人创建了子作用域并在其他注入的服务中解析了服务……最终注入了一个Scoped服务。
实践指南：
- Scoped服务可以认为是在Web请求中注入太多服务的一种优化。因此，在相同的Web请求期间，所有这些服务都将使用该服务的单个实例。
- Scoped服务无需设计为线程安全的。因为，它们应该正常地被单个Web请求或线程使用。但是，这这种情况下，你不应该在不同的线程之间共享服务作用域。
- 在Web请求中，如果你设计一个Scoped服务在其他服务之间共享数据，请小心（上面解释过）。你可以在HttpContext中存储每个Web请求的数据（注入IHttpContextAccessor 来访问它），这是共享数据的更安全的方式。 HttpContext的生命周期不是Scoped类型的，事实上，它根本不会被注册到DI（这也是为什么不注入它，而是注入 IHttpContextAccessor来代替）。HttpContextAccessor 的实现采用 AsyncLocal 在Web请求期间共享同一个 HttpContext.
结论：
依赖注入刚开始看起来很容易使用，但是如果你不遵循一些严格的原则，则会有潜在的多线程问题和内存泄漏问题。我分享的这些实践指南基于我在开发ABP框架期间的个人经验。