ASP.NET Core扩展库中服务注册模式的设计思考：以Redaction服务为例

服务注册的两种模式

在ASP.NET Core的依赖注入系统中，服务注册存在两种典型模式：

1. 强制注册(Add)：无论之前是否注册过相同服务，都会强制添加新注册
2. 尝试注册(TryAdd)：仅当服务尚未注册时才会执行注册操作

问题背景

在Microsoft.Extensions.DependencyInjection.RedactionServiceCollectionExtensions中，AddRedaction方法采用了TryAddSingleton实现，这与方法名的字面含义"Add"存在潜在的不一致。这种设计选择在实际使用中可能导致以下场景：

当开发者尝试为IRedactorProvider接口提供自定义实现时：

services.TryAddSingleton<IRedactorProvider>(...);
services.AddRedaction();

由于TryAdd的语义，后续的AddRedaction调用不会覆盖先前的注册，这可能与开发者预期不符。

框架设计哲学

通过分析ASP.NET Core框架内部实现，我们可以发现这种设计并非特例，而是遵循了框架的通用模式：

1. 框架扩展方法通常采用TryAdd作为默认实现
2. 这种设计保证了：
   • 不会意外覆盖用户自定义的注册
   • 提供了合理的默认实现
   • 保持了框架各组件间的一致性

实际应用建议

对于需要确保特定实现被使用的场景，开发者可以：

1. 明确注册顺序：

// 先添加框架默认实现
services.AddRedaction();

// 再覆盖自定义实现
services.AddSingleton<IRedactorProvider>(...);

2. 创建明确的配置方法：

public static IServiceCollection AddCustomRedaction(this IServiceCollection services)
{
    services.AddRedaction();
    // 自定义配置
    return services;
}

兼容性考量

在需要同时支持新旧两种Redaction实现的过渡期，可以采用适配器模式：

services.AddSingleton<Legacy.IRedactorProvider>(sp => 
    new LegacyRedactorAdapter(sp.GetRequiredService<IRedactorProvider>()));

这种设计既保证了新组件的正确注册，又为旧组件提供了兼容层。

总结

ASP.NET Core扩展库中的这种设计体现了框架对稳定性和可扩展性的重视。理解这种模式有助于开发者：

• 更准确地预测框架行为
• 编写更健壮的集成代码
• 设计更合理的组件架构

在实际开发中，开发者应当注意方法命名与实际行为的潜在差异，特别是在处理关键基础服务时，通过明确的注册顺序或自定义扩展方法来确保预期行为。