Fornjot项目中的验证基础设施改进方案

背景介绍

Fornjot是一个CAD建模工具，其验证机制在确保模型有效性方面扮演着关键角色。现有的验证代码负责检查形状的有效性，识别可能导致后续处理问题（如导出STL或3MF格式时产生无效网格）的各种情况。

现有验证机制分析

当前验证系统的主要特点是：

• 按对象组织验证检查（每个检查针对特定类型的对象）
• 所有验证检查采用相似的结构
• 验证错误信息与对象紧密耦合

这种设计虽然可行，但在代码组织、文档化和复用性方面存在一定局限性。

改进方案设计

核心概念

改进方案包含两个关键部分：

1. 独立验证检查类型：每个验证检查将被实现为独立的Rust类型，而非现有方案中作为对象特定验证错误类型的方法。这种设计允许更清晰的文档组织和代码复用。

2. 参数化验证特性：重构后的Validate trait将采用泛型参数，针对不同类型的验证检查提供特定实现。

技术实现细节

验证检查类型定义

每个验证检查将被定义为独立结构体：

struct SomeValidationCheck {
    // 包含验证失败相关信息的字段
}

这种设计使得每个验证检查可以拥有自己的模块，而非按对象组织。例如，Sketch和Solid共有的"禁止多引用"检查可以共享同一验证检查实现。

参数化Validate特性

改进后的特性定义可能如下：

trait Validate<T> where T: Into<ValidationError> {
    fn validate(&self, errors: &mut Vec<ValidationError>);
}

具体实现示例：

impl Validate<SomeValidationCheck> for SomeObject {
    // 实现细节
}

架构优势分析

1. 文档组织优化：每个验证检查拥有独立的文档空间，对象文档不再需要包含大量验证细节，只需引用相关验证检查即可。

2. 可发现性提升：所有与对象相关的验证检查会自然出现在对象的文档页面中（通过trait实现列表展示）。

3. 代码复用增强：相似验证检查可以更容易地在不同对象间共享实现。

4. 类型系统利用：Rust的类型系统被更充分地用于组织和管理验证逻辑。

实施考量

在具体实现过程中，开发团队需要解决几个关键问题：

1. 命名规范：是采用"验证检查"(ValidationCheck)还是"验证错误"(ValidationError)作为类型名称更合适？

2. 错误处理策略：是在trait方法中直接处理ValidationError，还是在外部进行转换？

3. 批量验证机制：如何组织执行对象的所有验证检查？是否需要引入二级trait（如ValidateAll）？

项目演进

在实际开发过程中，该改进方案经历了多次迭代：

1. 初期主要关注架构设计和原型验证
2. 逐步迁移现有验证检查到新架构
3. 最终因项目整体架构的重大调整（2025年3月的新架构实验）而暂停

经验总结

Fornjot项目的验证基础设施改进展示了在复杂系统中重构关键组件的典型挑战：

1. 架构设计需要平衡即时需求与长期可维护性
2. 文档组织和代码可发现性对开发者体验至关重要
3. 项目方向的重大调整可能影响正在进行的技术改进

尽管最终该改进方案因项目架构调整而暂停，但其设计理念和实现经验为后续开发提供了有价值的参考。