Semantic Kernel .NET 内存连接器设计优化：移除I*VectorStoreRecordCollectionFactory接口

在开发基于Semantic Kernel的向量存储功能时，设计团队最近对内存连接器的API进行了重新审视和优化。本文将深入探讨这一设计决策背后的技术考量和实现方案。

背景与现状

当前Semantic Kernel的.NET实现中，每个内存连接器都包含一个可选的IVectorStoreRecordCollectionFactory接口。这个接口允许用户在VectorStoreOptions中提供一个集合工厂，用于自定义当调用IVectorStore.CreateCollection()方法时如何创建集合。

这种设计模式在初期看起来提供了灵活性，但随着项目的发展，团队发现它带来了一些不必要的复杂性。主要问题在于：

1. 增加了API的复杂度，需要维护额外的接口和工厂类
2. 用户已经可以通过直接实例化IVectorStoreRecordCollection实现类来达到相同目的
3. 工厂接口的使用实际上还是需要用户了解特定提供商的实现细节

设计优化方案

经过深入讨论，团队决定采用更简洁的设计方案：

1. 移除I*VectorStoreRecordCollectionFactory接口：不再通过工厂模式来创建集合
2. 推荐使用继承和重写：用户可以通过扩展特定提供商的IVectorStore实现类（如MyModifiedQdrantVectorStore）来定制集合创建行为
3. 保持核心抽象：仍然保留IVectorStore作为主要抽象接口

这种方案的优势在于：

• 减少了公共API的数量，使系统更易于理解和维护
• 提供了同等的灵活性，甚至更大的控制权
• 遵循了.NET生态中更常见的扩展模式

技术实现细节

对于需要自定义集合创建行为的场景，现在推荐的做法是：

public class CustomQdrantVectorStore : QdrantVectorStore
{
    public CustomQdrantVectorStore(/* 参数 */) : base(/* 参数 */)
    {
    }
    
    public override IVectorStoreRecordCollection CreateCollection(string collectionName)
    {
        // 自定义集合创建逻辑
        return new CustomRecordCollection(/* 自定义参数 */);
    }
}

这种方法比原来的工厂模式更加直观，也更容易调试和维护。用户可以直接看到整个创建流程，而不需要通过工厂接口间接操作。

对现有代码的影响

这一变更属于破坏性变更，但影响范围有限：

1. 现有使用工厂接口的代码需要迁移到新的继承模式
2. 迁移过程相对直接，因为功能等价
3. 文档和示例需要相应更新

团队建议在下一个主要版本中实施这一变更，遵循语义化版本控制原则。

设计原则体现

这一优化体现了几个重要的软件设计原则：

1. 最少知识原则：减少用户需要了解的接口数量
2. 开闭原则：通过继承扩展而不是修改来满足新需求
3. 单一职责原则：每个类/接口的职责更加明确

结论

通过移除I*VectorStoreRecordCollectionFactory接口，Semantic Kernel的.NET内存连接器设计变得更加简洁和灵活。这一变更不仅减少了API的复杂度，还提供了更符合.NET开发者习惯的扩展方式。

对于高级用户来说，新的继承模式提供了更大的控制权和更清晰的代码结构。对于普通用户，简化的API使得学习和使用Semantic Kernel的内存功能更加容易。

这一设计优化是Semantic Kernel持续改进其API设计的一部分，旨在为开发者提供更优质、更符合工程实践的工具集。