如何为依赖Options的一组服务构建IServiceCollection扩展方法

经常碰到开发者问这类问题——把一组依赖配置选项的服务封装成DI扩展方法时，到底该怎么处理Options的配置？结合你的场景，我给你梳理两种合理的实现方案，帮你做出最适合的选择。

方案一：保持灵活性，让调用者自行配置Options #

这种方案是最贴合ASP.NET Core原生设计的思路：扩展方法只负责注册服务，Options的配置交给调用者自己处理。

扩展方法代码 #

public static IServiceCollection AddServices(this IServiceCollection services)
{
    // 只专注于服务的DI注册，不涉及Options配置
    return services
        .AddTransient<IServiceOne, ServiceOne>()
        .AddTransient<IServiceTwo, ServiceTwo>();
}

调用方式 #

builder.Services
    .AddServices()
    .Configure<ServiceOneOptions>(builder.Configuration.GetSection("ServiceOne"))
    .Configure<ServiceTwoOptions>(builder.Configuration.GetSection("ServiceTwo"));

优点：完全保留灵活性，调用者可以自由选择从配置文件、代码硬编码、数据库甚至外部API加载Options，还能多次调用Configure来叠加配置逻辑。
缺点：调用者需要清楚每个服务对应的Options类型和配置路径，对新手来说稍微有点繁琐。

方案二：把Options配置整合进扩展方法，简化调用 #

如果想让调用者用起来更省心，可以把Options的配置逻辑也封装到扩展里，这里有两种更友好的实现思路：

思路1：传入多个配置委托，沿用原生风格 #

这种方式让调用者用熟悉的Configure风格来配置每个服务的Options，我们在扩展里完成注册和配置的绑定：

扩展方法代码

public static IServiceCollection AddServices(
    this IServiceCollection services,
    Action<ServiceOneOptions> configureServiceOne,
    Action<ServiceTwoOptions> configureServiceTwo)
{
    // 先配置各个Options
    services.Configure(configureServiceOne);
    services.Configure(configureServiceTwo);
    
    // 再注册服务
    return services
        .AddTransient<IServiceOne, ServiceOne>()
        .AddTransient<IServiceTwo, ServiceTwo>();
}

调用方式

从配置文件加载：

builder.Services.AddServices(
    configureServiceOne: options => builder.Configuration.GetSection("ServiceOne").Bind(options),
    configureServiceTwo: options => builder.Configuration.GetSection("ServiceTwo").Bind(options)
);

或者硬编码配置：

builder.Services.AddServices(
    configureServiceOne: options => { options.ApiKey = "dev-key-123"; },
    configureServiceTwo: options => { options.Timeout = TimeSpan.FromSeconds(15); }
);

优点：调用者不用记住多个Configure调用，代码更简洁，同时保留了原生配置的灵活性。
缺点：如果后续新增服务，需要修改扩展方法的参数列表。

思路2：用统一配置对象包装所有子选项 #

这就是你自己构思的方案，我们可以把所有服务的Options封装到一个统一的ServicesOptions里，让调用者一次性配置，再在扩展里拆分注册：

配置类和扩展方法代码

public class ServicesOptions
{
    // 初始化空实例，避免调用者出现空引用
    public ServiceOneOptions One { get; set; } = new ServiceOneOptions();
    public ServiceTwoOptions Two { get; set; } = new ServiceTwoOptions();
}

public static IServiceCollection AddServices(
    this IServiceCollection services,
    Action<ServicesOptions> configure)
{
    var servicesOptions = new ServicesOptions();
    configure(servicesOptions);
    
    // 将子选项注册为IOptions（推荐用Configure支持后续重新配置）
    services.Configure<ServiceOneOptions>(o => 
    {
        // 手动复制属性，或者用AutoMapper/ObjectModel的CopyFrom简化
        o.ApiKey = servicesOptions.One.ApiKey;
        o.BaseUrl = servicesOptions.One.BaseUrl;
    });
    services.Configure<ServiceTwoOptions>(o => 
    {
        o.Timeout = servicesOptions.Two.Timeout;
        o.MaxRetryCount = servicesOptions.Two.MaxRetryCount;
    });
    
    // 注册服务
    return services
        .AddTransient<IServiceOne, ServiceOne>()
        .AddTransient<IServiceTwo, ServiceTwo>();
}

调用方式

builder.Services.AddServices(options => 
{
    builder.Configuration.GetSection("ServiceOne").Bind(options.One);
    builder.Configuration.GetSection("ServiceTwo").Bind(options.Two);
});

优点：调用者能清晰看到所有需要配置的选项，不用分散处理多个Configure。
缺点：如果某个服务的Options结构变化，ServicesOptions也要跟着修改，手动复制属性有点繁琐（可以用工具类简化）。

最终推荐 #

• 如果你的服务库需要给调用者最大的灵活性（比如支持多种配置来源、动态修改配置），方案一是最优选择，符合ASP.NET Core的惯用模式。
• 如果你的目标是尽可能简化调用者的代码，方案二的思路1更合适，它沿用了原生配置的风格，学习成本低，代码简洁。

内容来源于stack exchange