.NET扩展库中ChatClient构建器模式的优化探讨

在.NET扩展库的开发过程中，团队正在讨论如何优化ChatClient的依赖注入和构建器模式。当前的设计虽然功能完善，但在API的易用性和直观性方面还有提升空间。

当前实现分析

目前ChatClient的构建采用以下模式：

services.AddChatClient(pipeline => pipeline
    .UseDistributedCache()
    .UseFunctionCalling()
    .Use(new SomeConcreteClient());

这种设计存在几个可以改进的地方：

1. 需要额外的lambda表达式(pipeline => pipeline)
2. 构建逻辑嵌套在方法调用中
3. 终止管道的Use方法与中间件Use方法语义相似但行为不同

优化方案

团队提出的改进方案是将构建器直接作为返回值：

services.AddChatClient(new SomeConcreteClient())
    .UseDistributedCache()
    .UseFunctionCalling();

这种模式在.NET生态中已有先例，具有以下优势：

1. 消除了冗余的lambda表达式
2. 构建链更加线性直观
3. 符合常见的DI扩展方法设计模式

技术挑战与解决方案

实现这一优化需要解决几个技术问题：

1. 服务提供者延迟访问：

   • 原设计在构造时依赖IServiceProvider
   • 新方案需要将服务提供者访问推迟到实际解析时
   • 解决方案是调整Use方法重载，统一使用Func<IServiceProvider,...>

2. 终止方法设计：

   • 原Use(IChatClient)方法需要改为工厂模式
   • 考虑重命名为UseInnerClient或Build以明确语义
   • 替代方案是将终止客户端作为构造函数参数

3. 默认管道处理：

   • 原设计通过检查null pipeline来应用默认管道
   • 新方案需要跟踪Use调用状态
   • 或者考虑移除默认管道概念，要求显式配置

设计建议

基于讨论，建议采用以下最佳实践：

1. 明确构建阶段：

   • 构造函数接受终止客户端(或工厂)
   • Use方法仅用于中间件配置
   • 构建完成后不可再修改

2. 简化API设计：

   • 移除默认管道逻辑
   • 要求开发者显式配置所需功能
   • 提供示例代码展示常见配置模式

3. 命名一致性：

   • 区分中间件Use和终止Use方法
   • 考虑Build或Complete作为终止方法名
   • 保持与.NET生态命名惯例一致

这种优化不仅提升了API的易用性，也使代码更加符合.NET开发者的预期模式，有利于降低学习成本和提高开发效率。