.NET基控制器使用IServiceProvider：两种实现的优劣与最佳实践咨询

方案背景 #

在.NET开发中，开发者提出两种基控制器的实现方案：

方案1：注入IServiceProvider获取服务 #

通过注入IServiceProvider，在构造函数中获取所需服务，可添加缓存字典优化服务获取：

[Authorize]
public abstract partial class BaseSecureController : Controller
{
    private readonly IServiceProvider _serviceProvider;

    protected readonly ISender _sender;
    protected readonly Guid? _userId;

    public BaseSecureController(IServiceProvider ServiceProvider) 
    {
        _serviceProvider = ServiceProvider;

        _sender = _serviceProvider.GetRequiredService<ISender>();

        _userId = _serviceProvider.GetRequiredService<IUserContext>().UserId();

        GeneralGuards.AgainstNullUserId(_userId);
    }
}

方案2：直接注入具体服务 #

直接在构造函数中声明所需的服务依赖，由继承的控制器传递依赖：

[Authorize]
public abstract partial class BaseSecureController : Controller
{
    protected readonly ISender _sender;
    protected readonly Guid? _userId;

    public BaseSecureController(ISender sender, IUserContext userContext) 
    {
        _sender = sender;
        _userId = userContext?.UserId();

        GeneralGuards.AgainstNullUserId(_userId);
    }
}

各维度对比分析 #

1. 单元测试角度 #

方案2更优：

• 直接注入的依赖在单元测试中可轻松通过Mock框架（如Moq）创建模拟实例，测试逻辑清晰，只需关注目标依赖的行为。
• 方案1需要模拟整个IServiceProvider，并针对每个GetRequiredService调用设置返回值，测试代码冗余复杂，易因服务获取逻辑变动导致测试失败。

2. 最佳实践角度 #

方案2完全符合显式依赖原则，是DI的最佳实践：

• 基类构造函数清晰展示所有依赖，其他开发者能快速理解类的依赖关系，维护成本低。
• 方案1采用服务定位器模式，属于DI反模式：隐藏真实依赖，导致代码可读性差，后期易出现随意通过IServiceProvider添加新依赖的情况，让依赖关系逐渐混乱，难以追踪维护。

3. 长期性能角度 #

方案2的性能更稳定高效：

• DI容器初始化时会提前解析并注入所需服务，直接注入无需额外查找或反射操作，能享受到DI容器的优化（如单例服务复用）。
• 方案1即使添加缓存字典，首次获取服务仍需通过IServiceProvider查找，缓存本身也会占用额外内存；后续虽有缓存，但始终多了一层服务定位的调用开销，长期累积的性能损耗不可忽视。

方案1服务数量增加的性能影响 #

随着服务数量增加，方案1的性能会受到明显影响：

• 每新增一个服务，就需要多一次GetRequiredService调用，初始化阶段的服务查找次数线性增加，即使有缓存，首次初始化开销也会随服务数量上升而变大。
• 如果涉及瞬时服务，每次通过IServiceProvider获取都会触发实例创建，额外的调用逻辑会增加性能损耗；同时，依赖越多，服务定位器模式带来的维护成本上升远大于性能问题，会让代码逐渐难以维护。

内容的提问来源于stack exchange，提问作者Hakuna