.NET Extensions 中 IChatClient 依赖注入生命周期扩展的演进

在 .NET Extensions 项目的 AI 组件开发过程中，开发团队发现了一个关于 IChatClient 服务注册生命周期的重要设计问题。本文将深入分析这个问题及其解决方案，帮助开发者理解服务生命周期在依赖注入中的重要性。

问题背景

在当前的 Microsoft.Extensions.AI 包中，ChatCompletion 相关的服务注册扩展方法默认使用了 Singleton（单例）生命周期。这种硬编码的设计在某些场景下会带来限制，特别是当 ChatClient 需要与请求特定的上下文（如 GitHub Copilot 代理中的访问令牌）绑定时。

技术分析

Singleton 生命周期意味着整个应用程序中只会创建一个服务实例。这种设计对于无状态的、线程安全的服务是理想的，但对于以下场景则存在问题：

1. 需要根据请求上下文动态配置的服务
2. 需要维护请求特定状态的服务
3. 需要隔离不同请求间数据的服务

在 GitHub Copilot 代理场景中，ChatClient 需要与每个请求的 GitHub 访问令牌关联，这就要求服务实例的生命周期应该限定在请求范围内（Scoped）。

解决方案演进

开发团队考虑了两种主要的解决方案：

1. 多方法方案：创建多个扩展方法，如 AddSingletonChatClient、AddScopedChatClient 等。这种方案符合 .NET 依赖注入的命名惯例，但会带来 API 膨胀的问题。

2. 参数化方案：借鉴 Entity Framework Core 的设计，在现有方法中添加 ServiceLifetime 参数。例如：

   services.AddChatClient(config => { ... }, ServiceLifetime.Scoped);
   

经过讨论，团队更倾向于第二种方案，因为它：

• 保持了 API 的简洁性
• 与现有 .NET 生态系统的设计模式一致
• 提供了更大的灵活性而不增加 API 表面积

实现建议

最终的实现应该考虑以下方面：

1. 保持向后兼容性，默认仍使用 Singleton 生命周期
2. 添加新的重载方法接受 ServiceLifetime 参数
3. 确保文档清晰地说明不同生命周期的适用场景

最佳实践

开发者在使用 ChatClient 注册时，应根据具体场景选择适当的生命周期：

• Singleton：适用于无状态、线程安全的客户端，性能最优
• Scoped：需要与请求上下文关联的场景
• Transient：极少使用，除非每次调用都需要全新实例

总结

这个改进展示了 .NET 生态系统中依赖注入设计的灵活性。通过参数化生命周期配置，Microsoft.Extensions.AI 包能够更好地适应各种应用场景，同时保持了 API 的简洁性和一致性。这种设计模式也值得在其他需要灵活生命周期管理的服务注册场景中借鉴。