Service Fabric中如何保留依赖注入调用Controller方法

首先得说句实在的：直接去拿启动时实例化的Controller并不是个好主意——Controller的生命周期原本是和HTTP请求绑定的（通常是Scoped，每次请求创建一个新实例），而你的CommandInstanceHandler是后台运行的服务组件，两者生命周期不匹配，硬凑在一起很容易踩依赖注入的坑，还违反了单一职责原则。

推荐方案：抽离业务逻辑到独立服务（最佳实践） #

正确的做法是把Controller里的核心业务逻辑抽出来，放到一个独立的业务服务类中，让Controller和CommandInstanceHandler都依赖这个服务。这样既解耦，又能复用逻辑，还符合DI的设计思路。

举个具体的例子：

1. 定义业务服务接口与实现

// 抽象业务逻辑的接口
public interface IOrderProcessingService
{
    Task ProcessOrderAsync(OrderCommand command);
}

// 实现具体业务逻辑
public class OrderProcessingService : IOrderProcessingService
{
    private readonly IDatabaseService _dbService;
    private readonly ILoggingService _loggingService;

    // 注入服务需要的所有依赖
    public OrderProcessingService(IDatabaseService dbService, ILoggingService loggingService)
    {
        _dbService = dbService;
        _loggingService = loggingService;
    }

    public async Task ProcessOrderAsync(OrderCommand command)
    {
        // 这里放原来Controller里的业务逻辑
        await _dbService.SaveOrder(command);
        _loggingService.LogInfo($"Processed order {command.OrderId}");
    }
}

2. 让Controller依赖这个服务

[ApiController]
[Route("api/orders")]
public class OrdersController : ControllerBase
{
    private readonly IOrderProcessingService _processingService;

    public OrdersController(IOrderProcessingService processingService)
    {
        _processingService = processingService;
    }

    [HttpPost]
    public async Task<IActionResult> ProcessOrder([FromBody] OrderCommand command)
    {
        await _processingService.ProcessOrderAsync(command);
        return Ok("Order processed successfully");
    }
}

3. 让CommandInstanceHandler也依赖这个服务

public class CommandInstanceHandler
{
    private readonly IOrderProcessingService _processingService;

    // 通过构造函数注入业务服务
    public CommandInstanceHandler(IOrderProcessingService processingService)
    {
        _processingService = processingService;
    }

    public async Task HandleServiceBusMessageAsync(ServiceBusMessage message)
    {
        // 解析Service Bus消息为命令对象
        var orderCommand = ParseMessageToCommand(message);
        // 直接调用业务服务的方法
        await _processingService.ProcessOrderAsync(orderCommand);
    }

    private OrderCommand ParseMessageToCommand(ServiceBusMessage message)
    {
        // 消息解析逻辑
        return JsonSerializer.Deserialize<OrderCommand>(message.Body.ToString());
    }
}

4. 在Startup中注册服务

public void ConfigureServices(IServiceCollection services)
{
    // 注册业务服务（根据需求选择Scoped/Singleton/Transient）
    services.AddScoped<IOrderProcessingService, OrderProcessingService>();
    // 注册其他依赖（比如数据库、日志服务）
    services.AddScoped<IDatabaseService, DatabaseService>();
    services.AddSingleton<ILoggingService, LoggingService>();
    // 注册Controller和Handler
    services.AddControllers();
    services.AddSingleton<CommandInstanceHandler>();
}

不推荐的应急方案：通过DI容器获取Controller实例 #

如果因为某些限制必须直接调用Controller，也可以通过IServiceProvider创建作用域来获取Controller实例，但一定要注意生命周期问题：

public class CommandInstanceHandler
{
    private readonly IServiceProvider _serviceProvider;

    public CommandInstanceHandler(IServiceProvider serviceProvider)
    {
        _serviceProvider = serviceProvider;
    }

    public async Task HandleMessageAsync(ServiceBusMessage message)
    {
        // 创建一个新的作用域，确保Scoped依赖能正确解析
        using var scope = _serviceProvider.CreateScope();
        var controller = scope.ServiceProvider.GetRequiredService<OrdersController>();
        
        var command = ParseMessageToCommand(message);
        var result = await controller.ProcessOrder(command);
        
        // 按需处理Controller返回的IActionResult
    }
}

⚠️ 注意：这种方式相当于把Controller当成普通服务使用，完全忽略了它作为HTTP请求处理者的设计初衷，很容易引发依赖生命周期冲突（比如在Singleton的Handler中使用Scoped依赖），所以除非万不得已，强烈不建议这么做。

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