如何在.NET Core的AWS Lambda函数中配置DI容器并落地SOLID原则

我来分享一套适用于AWS Lambda的DI容器接入方案，同时通过基类架构践行SOLID原则——完美解决Lambda没有Startup.cs的问题，还能轻松拆分大型函数的可测试组件。

核心思路 #

我们自定义一个Startup基类，负责初始化依赖注入容器，让Lambda函数类继承这个基类，从而在函数中通过服务解析方法获取依赖。这样既保留了.NET Core DI的灵活性，又能让组件解耦、易于测试。

代码实现步骤 #

1. 编写Startup基类 #

这个基类封装了DI容器的构建逻辑，同时提供抽象方法让子类注册自己的服务：

using Microsoft.Extensions.DependencyInjection;

public abstract class Startup
{
    protected IServiceProvider ServiceProvider { get; set; }

    protected Startup()
    {
        var services = new ServiceCollection();
        ConfigureServices(services);
        ServiceProvider = services.BuildServiceProvider();
    }

    // 让子类实现该方法，注册自身需要的服务
    protected abstract void ConfigureServices(IServiceCollection services);

    // 提供通用的服务解析方法
    protected T GetRequiredService<T>() where T : notnull
    {
        return ServiceProvider.GetRequiredService<T>();
    }
}

2. 实现Lambda函数类 #

让你的Lambda函数继承Startup，并在ConfigureServices中注册依赖，通过基类的方法获取服务实例：

// 先定义服务接口和实现
public interface IFooService
{
    Task<string> DoSomething(string input);
}

public class FooService : IFooService
{
    public async Task<string> DoSomething(string input)
    {
        return await Task.FromResult($"Processed: {input}");
    }
}

// Lambda函数类
public class Function : Startup
{
    private readonly IFooService _fooService;

    public Function()
    {
        // 通过基类方法解析依赖
        _fooService = GetRequiredService<IFooService>();
    }

    // 注册服务到DI容器
    protected override void ConfigureServices(IServiceCollection services)
    {
        services.AddScoped<IFooService, FooService>();
        // 可以继续添加其他服务，比如仓储、日志等
    }

    // Lambda处理入口
    public async Task<string> FunctionHandler(string input, ILambdaContext context)
    {
        context.Logger.LogInformation($"Received input: {input}");
        return await _fooService.DoSomething(input);
    }
}

3. 编写可测试的单元测试 #

因为我们用了DI，所以可以轻松替换依赖为Mock对象，测试逻辑和真实环境完全隔离：

using Moq;
using Xunit;
using Microsoft.Extensions.DependencyInjection;

public class FunctionTests
{
    [Fact]
    public async Task FunctionHandler_ProcessesInputCorrectly()
    {
        // 1. 创建Mock服务
        var mockFooService = new Mock<IFooService>();
        mockFooService.Setup(s => s.DoSomething("test input"))
                      .ReturnsAsync("Mocked Processed: test input");

        // 2. 构建测试用的DI容器
        var services = new ServiceCollection();
        services.AddScoped(_ => mockFooService.Object);
        var testProvider = services.BuildServiceProvider();

        // 3. 创建测试用的Function实例（通过子类绕过基类的默认构造）
        var testFunction = new TestableFunction(testProvider);

        // 4. 执行测试
        var result = await testFunction.FunctionHandler("test input", null);

        // 5. 验证结果
        Assert.Equal("Mocked Processed: test input", result);
        mockFooService.Verify(s => s.DoSomething("test input"), Times.Once);
    }

    // 为测试创建的子类，允许传入自定义ServiceProvider
    private class TestableFunction : Function
    {
        public TestableFunction(IServiceProvider serviceProvider)
        {
            ServiceProvider = serviceProvider;
            _fooService = GetRequiredService<IFooService>();
        }
    }
}

如何践行SOLID原则 #

这套架构完美贴合SOLID：

• 单一职责：Function只负责处理Lambda请求和协调服务，FooService专注于业务逻辑，Startup只处理DI初始化
• 开闭原则：新增服务只需要在ConfigureServices中注册，无需修改核心逻辑
• 里氏替换：测试时用TestableFunction替换原Function，完全不影响功能验证
• 接口隔离：所有依赖都通过接口（如IFooService）注入，避免依赖具体实现
• 依赖倒置：高层模块（Function）依赖抽象接口，而非具体服务类，降低耦合

注意事项 #

• 冷启动优化：Lambda冷启动时会创建ServiceProvider，建议将无状态、复用性高的服务注册为Singleton，减少初始化开销
• 日志集成：可以在Startup中添加services.AddLogging()，注入ILogger到服务中，统一日志管理
• 原生DI替代：如果你的Lambda是基于ASP.NET Core托管的（用Amazon.Lambda.AspNetCoreServer），可以直接用ASP.NET Core的DI机制，无需自定义Startup基类

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