C#库接口设计最佳实践：封装DI实例获取方案咨询

相关标准与主流实践 #

• 封装实现细节的原则：你想隐藏DI细节、只暴露IFoo接口的思路，符合类库设计中“最小暴露”的核心原则，是合理的方向。不过微软DI并没有强制的标准静态获取方式，行业内更主流的做法是通过扩展方法帮助集成者完成服务注册，而非直接提供静态获取方法。
  示例扩展方法：

  public static IServiceCollection AddFoo(this IServiceCollection services)
  {
      services.AddScoped<IFoo, Foo>();
      // 在这里注册Foo所需的其他依赖项
      return services;
  }
  

  集成者只需在自己的DI配置中调用services.AddFoo()，既完成了所有必要的注册，又保留了对容器的控制权。
• 服务定位器的争议：你当前的静态GetFoo()本质是服务定位器模式，在DI场景中这通常被视为反模式——它会隐藏依赖关系，不利于测试和维护。

你的方案的劣势 #

• 依赖关系不透明：集成者无法直观知晓IFoo依赖哪些服务，排查问题或做自定义配置时会增加难度。单元测试中若要替换IFoo或其依赖，需要修改全局ServiceProvider，耦合度极高。
• 生命周期失控：如果Foo是Scoped或Transient类型，静态方法返回的实例可能无法遵循容器的生命周期规则，容易引发资源泄漏、状态混乱等问题。
• 扩展性差：集成者无法自定义Foo的注册方式（比如替换为自定义实现、调整生命周期），后续若要支持其他DI容器，静态方法的方式几乎无法兼容。

更合理的替代方案 #

1. 提供DI扩展方法：这是类库集成DI的标准做法，既封装了所有依赖注册逻辑，又给集成者保留了容器的控制权。
2. 使用工厂类而非静态方法：如果想简化实例获取，可以创建一个FooFactory，要求集成者传入IServiceProvider或通过DI注入工厂：

   public class FooFactory
   {
       private readonly IServiceProvider _sp;
       
       public FooFactory(IServiceProvider sp)
       {
           _sp = sp;
       }
       
       public IFoo GetFoo()
       {
           return _sp.GetRequiredService<IFoo>();
       }
   }
   

   这种方式避免了全局静态依赖，同时保留了封装性。
3. 直接暴露构造函数（简单场景）：如果Foo的依赖很少且都是公开类型，也可以让集成者直接通过构造函数实例化，但仅适合依赖简单的场景。

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