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

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

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

这些原则背后的目的是:

1. 有效地设计服务及其依赖关系
2. 防止多线程问题
3. 防止内存泄漏
4. 防止潜在的错误

本文假设你已经熟悉基本的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容器中）.

建议作法

1. 仅对可选依赖项使用属性注入。这意味着你的服务能够脱离这些依赖能正常工做.
2. 尽量得使用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),这点一样适用于构造函数注入和属性注入.

建议作法

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生命周期的服务中依赖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)

建议作法

1. 若是要在方法体中解析服务,请始终建立子服务范围以确保正确的释放已解析的服务.
2. 若是将IServiceProvider做为方法的参数，那么你能够直接从中解析服务而无需关心释放/处置(release/dispose). 建立/管理服务范围是调用方法的代码的责任. 遵循这一原则使你的代码更清晰.
3. 不要引用解析到的服务,否则它可能会致使内存泄漏或者在你之后使用对象引用时可能访问已处置的(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,不然缓存将没法按预期工做.

建议作法

1. 若是服务须要保持状态,则应以线程安全的方式访问该状态.由于全部请求同时使用相同的服务实例.我使用ConcurrentDictionary而不是Dictionary来确保线程安全.
2. 不要在单例服务中使用Scoped生命周期或Transient生命周期的服务.由于临时服务可能不是设计为线程安全.若是必须使用它们那么在使用这些服务时请注意多线程问题(例如使用锁).
3. 内存泄漏一般由单例服务引发.它们在应用程序结束前不会被释放/处置(release/dispose). 所以若是他们实例化的类(或注入)但不释放/处置(release/dispose).它们,它们也将留在内存中直到应用程序结束. 确保在正确的时间释放/处置(released/disposed)它们。 请参阅上面的在方法中的解析服务内容.
4. 若是缓存数据(本示例中的文件内容),则应建立一种机制,以便在原始数据源更改时更新/使缓存的数据无效(当上面示例中磁盘上的缓存文件发生更改时).

范围服务(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请求的实例。

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

建议作法

1. Scoped生命周期的服务能够被认为是在Web请求中由太多服务注入的优化.所以,全部这些服务将在同一Web请求期间使用该服务的单个实例.
2. Scoped生命周期的服务不须要设计为线程安全的. 由于它们一般应由单个Web请求/线程使用.可是...在这种状况下,你不该该在不一样的线程之间共享Scoped生命周期服务!
3. 若是你设计Scoped生命周期服务以在Web请求中的其余服务之间共享数据,请务必当心(如上所述). 你能够将每一个Web请求数据存储在HttpContext中(注入IHttpContextAccessor以访问它),这是更安全的方式. HttpContext的生命周期不是做用域. 实际上它根本没有注册到DI(这就是为何你不注入它，而是注入IHttpContextAccessor). HttpContextAccessor使用AsyncLocal实如今Web请求期间共享相同的HttpContext.

结论

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

原文地址:ASP.NET Core Dependency Injection Best Practices, Tips & Tricks