ASP.NET Extensions 中 AIContent 类的可扩展性优化探讨

在 ASP.NET Extensions 项目中，AI 相关功能的开发团队最近针对 AIContent 类的设计进行了一次重要的讨论。这个类作为 AI 内容的基础表示形式，其设计直接影响到开发者在处理 AI 内容时的灵活性和便利性。

当前设计面临的挑战

AIContent 类目前的设计存在一个关键限制：它是一个非抽象类，但构造函数被标记为 protected。这种设计导致了一些使用场景上的不便：

1. 当 AI 服务提供商需要表示特定类型的内容时，他们必须创建 AIContent 的子类
2. 如果提供商不希望公开这些子类，只能将其设为 internal 类型
3. 在 Native AOT 编译场景下，这种设计会导致 JSON 序列化问题，因为消费者无法将这些内部类型注册到 JsonSerializerOptions 中

解决方案探讨

开发团队提出了一个改进方案：将 AIContent 类的构造函数改为 public，使其可以直接实例化。这一改动将带来几个显著优势：

1. 简化类型系统：服务提供商可以直接使用基础 AIContent 类，而不必强制创建子类
2. 更好的封装性：提供商可以选择不暴露特定内容类型的实现细节
3. Native AOT 兼容性：基础类型可以直接用于 JSON 序列化，无需注册所有可能的子类

技术实现细节

为了支持这一改进，团队还讨论了 JSON 序列化的处理策略。通过使用 JsonPolymorphic 属性，可以实现以下行为：

[JsonDerivedType(typeof(Derived1), typeDiscriminator: "first")]
[JsonDerivedType(typeof(Derived2), typeDiscriminator: "second")]
[JsonPolymorphic(IgnoreUnrecognizedTypeDiscriminators = true, 
                UnknownDerivedTypeHandling = JsonUnknownDerivedTypeHandling.FallBackToBaseType)]
class MyBase;

这种配置允许：

• 识别已知的子类型（如 Derived1 和 Derived2）
• 对于未知类型，回退到基类进行反序列化
• 忽略无法识别的类型标识符

设计权衡与决策

在讨论过程中，团队也考虑了潜在的问题：

1. 数据丢失风险：当回退到基类时，子类特有的属性可能会丢失
2. 显式与隐式行为：是否应该强制开发者明确注册所有子类型

最终，团队倾向于优先考虑简化 API 表面和提升易用性，认为允许回退到基类的方案更符合大多数使用场景的需求，特别是对于那些只需要基础功能的消费者。

结论

这一设计变更将使 ASP.NET Extensions 中的 AI 功能更加灵活和易于使用，特别是在需要与多种 AI 服务集成的场景下。通过使 AIContent 类可直接实例化并改进其序列化行为，开发者将能够更轻松地处理各种 AI 生成内容，同时保持代码的简洁性和可维护性。