Blazor中依赖注入服务依赖其他服务的最佳实践探讨

以微软官方的Blazor Server模板（通过dotnet new blazorserver创建）为场景：假设WeatherForecastService依赖外部数据服务IDataService获取数据，相关接口与实现定义如下：

public interface IDataService
{
    public string GetData();
}

public class DataService : IDataService
{
    public string GetData()
    {
        // 此处可实现与外部服务的交互逻辑
        return "Some Data Here";
    }
}

我考虑了两种在WeatherForecastService中使用IDataService的方式：

选项1：方法定义中注入依赖 #

在需要的方法里直接传入依赖实例，比如给WeatherForecastService添加如下方法：

public string GetDataFromDataService(IDataService service)
{
    return service.GetData();
}

优点 #

• Program.cs中服务注册简单，示例：builder.Services.AddSingleton<IDataService>(new DataService());
• 该IDataService实例可被其他需要的服务复用

缺点 #

• 每个需要依赖的方法都得传参，代码易混乱
• 注入WeatherForecastService的组件可能还需额外注入IDataService，增加组件依赖负担

选项2：类构造函数中注入依赖 #

将IDataService注入WeatherForecastService的构造函数，作为类成员复用：

private IDataService _dataService { get; }
public WeatherForecastService(IDataService dataService)
{
    _dataService = dataService;
}
public string GetDataFromDataService()
{
    return _dataService.GetData();
}

优点 #

• 依赖只需注入一次，可在类内所有方法中复用

缺点 #

• 你之前提到的“服务无法供其他服务使用”是误解，只要IDataService在DI容器中注册为公共服务，其他服务也能注入；真正的问题是如果手动实例化WeatherForecastService，会绕开DI容器的自动解析
• 若手动实例化服务，可能写出不规范的注册代码，比如：

  var dataService = new DataService();
  builder.Services.AddSingleton(new WeatherForecastService(dataService));
  

其他方案与最佳实践 #

其他可行方案 #

1. 属性注入：借助第三方DI容器（如Autofac）的属性注入功能，通过标记属性让容器自动填充类的属性成员。示例（Autofac下）：

   public class WeatherForecastService
   {
       [Inject]
       public IDataService DataService { get; set; }
   
       public string GetDataFromDataService()
       {
           return DataService.GetData();
       }
   }
   

   注意：ASP.NET Core原生DI默认不支持此方式，且该方法会让类的依赖关系不明确，不推荐作为常规方案。

2. 工厂模式：创建服务工厂类，负责按需创建WeatherForecastService并注入依赖，避免手动实例化的问题。示例：

   public interface IWeatherForecastServiceFactory
   {
       WeatherForecastService Create();
   }
   
   public class WeatherForecastServiceFactory : IWeatherForecastServiceFactory
   {
       private readonly IDataService _dataService;
   
       public WeatherForecastServiceFactory(IDataService dataService)
       {
           _dataService = dataService;
       }
   
       public WeatherForecastService Create()
       {
           return new WeatherForecastService(_dataService);
       }
   }
   

   注册方式：

   builder.Services.AddSingleton<IDataService, DataService>();
   builder.Services.AddSingleton<IWeatherForecastServiceFactory, WeatherForecastServiceFactory>();
   

   使用时从工厂获取实例即可。

最佳实践 #

在Blazor（以及整个ASP.NET Core生态）中，构造函数注入是官方推荐的最佳实践，原因如下：

• 依赖关系清晰，类的构造函数明确展示了它需要哪些服务才能工作
• 符合依赖倒置原则，依赖抽象而非具体实现
• 原生DI容器完美支持，无需额外扩展
• 便于单元测试，可轻松传入模拟的IDataService实例

针对你之前提到的构造函数注入的“缺点”，纠正两点：

1. IDataService只要在DI容器中注册为单例/作用域/瞬时服务，其他服务完全可以注入使用，不存在“无法供其他服务使用”的问题
2. 不需要手动实例化WeatherForecastService，正确的注册方式应该是：

   builder.Services.AddSingleton<IDataService, DataService>();
   builder.Services.AddSingleton<WeatherForecastService>();
   

   这样DI容器会自动解析WeatherForecastService的构造函数依赖，无需手动创建DataService实例。只有当依赖的服务需要特殊配置时，才需要使用工厂方法或委托注册，比如：

   builder.Services.AddSingleton<IDataService, DataService>(sp => 
   {
       // 这里可以添加DataService的初始化逻辑
       return new DataService();
   });
   builder.Services.AddSingleton<WeatherForecastService>();
   

总结 #

• 优先选择构造函数注入，这是ASP.NET Core官方推荐的标准方式，清晰且易于维护
• 方法参数注入仅适用于临时、一次性的依赖场景，不适合作为常规方案
• 属性注入和工厂模式可作为特殊场景下的补充，但不推荐作为首选

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