SqlDatabaseVectorSearch项目中的文件格式扩展机制设计
在SqlDatabaseVectorSearch项目中,当前仅支持PDF文件格式的解析功能,且相关代码直接硬编码在VectorSearchService.cs文件中。这种实现方式存在明显的扩展性问题,本文将探讨如何设计一个灵活的文件格式扩展机制,使项目能够轻松支持更多文档类型。
当前实现的问题分析
目前项目中PDF解析功能直接嵌入在核心服务类中,这种设计存在几个关键问题:
- 代码耦合度高:文件解析逻辑与核心服务紧密耦合,不利于维护
- 扩展性差:添加新文件格式需要修改核心服务代码,违反开闭原则
- 职责不单一:核心服务类承担了过多职责
改进方案设计
接口抽象
首先需要定义一个统一的文件解析接口:
public interface IFileParser
{
bool CanParse(string fileExtension);
Task<string> ParseAsync(Stream fileStream);
}
该接口包含两个关键方法:
CanParse
:判断是否支持特定文件扩展名ParseAsync
:实际执行文件解析
具体实现
对于PDF解析,可以创建单独的实现类:
public class PdfFileParser : IFileParser
{
public bool CanParse(string fileExtension) =>
fileExtension.Equals(".pdf", StringComparison.OrdinalIgnoreCase);
public async Task<string> ParseAsync(Stream fileStream)
{
// PDF解析实现代码
}
}
服务注册与解析
使用.NET的依赖注入系统,特别是Keyed Services功能,可以优雅地管理多个解析器:
// 服务注册
builder.Services.AddKeyedTransient<IFileParser, PdfFileParser>("pdf");
// 服务解析
var parser = _serviceProvider.GetKeyedService<IFileParser>(fileExtension);
工厂模式封装
为了简化客户端代码,可以引入工厂类:
public class FileParserFactory
{
private readonly IServiceProvider _serviceProvider;
public FileParserFactory(IServiceProvider serviceProvider)
{
_serviceProvider = serviceProvider;
}
public IFileParser GetParser(string fileExtension)
{
return _serviceProvider.GetKeyedService<IFileParser>(fileExtension.ToLower());
}
}
设计优势
- 开闭原则:新增文件格式只需添加新实现类,无需修改现有代码
- 可测试性:每个解析器可以单独测试
- 灵活性:可以根据运行时条件动态选择解析器
- 可维护性:代码结构清晰,职责分离
未来扩展方向
基于此设计,项目可以轻松扩展支持更多文件格式:
- Office文档:DOCX、XLSX等
- 纯文本:TXT、CSV等
- 电子书:EPUB、MOBI等
- 代码文件:CS、JS等
每种格式只需实现对应的解析器类并注册到DI容器即可。
实施建议
- 首先将现有PDF解析逻辑迁移到独立类
- 建立基础接口和工厂机制
- 逐步添加其他常见文档格式支持
- 考虑加入文件类型自动检测功能
- 可以引入策略模式处理复杂解析场景
这种设计将使SqlDatabaseVectorSearch项目具备强大的文档处理能力,同时保持代码的整洁和可维护性。
创作声明:本文部分内容由AI辅助生成(AIGC),仅供参考