多端点+具体对象 vs 单端点+动态对象：哪种方案更优？

现有代码定义 #

数据类

public class SomeClass
{
    public int SomeId { get; set; }

    public object Content { get; set; }
}

API端点

[HttpPost]
public async Task SomeTask(SomeClass entity)
{
    await _someService.Process(entity);
}

问题背景 #

Content属性的类型会根据SomeId的值变化（可为数组、元组或结构体），该差异在编译时已知。SomeId取值范围为1至20，且未来可能新增取值。当前需要在以下两个方案中选择更优解：

1. 为每个可能的SomeId值创建20+个独立端点，使用具体类定义替代object类型的Content；
2. 采用单端点+工厂模式，根据传入的SomeId决定处理逻辑，工厂需显式将object转换为具体类型。

本人倾向第二种方案，但对必须使用类型转换存在疑虑。

方案分析 #

方案1：多独立端点

• 优势：
  • 强类型校验，编译阶段就能发现类型不匹配的错误，避免运行时类型转换异常
  • 每个端点职责单一，逻辑清晰，API文档（如Swagger）会更直观，客户端调用时能明确知道每个接口的请求体结构
• 劣势：
  • 代码冗余度高，每个SomeId对应一套重复的端点、模型定义，新增取值时需要重复创建相似代码
  • 端点数量会随SomeId取值增加而膨胀，增加维护成本，客户端也需要根据SomeId切换不同的调用路径

方案2：单端点+工厂模式

• 优势：
  • 代码结构简洁，扩展性强，新增SomeId取值时仅需在工厂类中添加对应处理分支，无需修改端点定义
  • 客户端只需调用统一接口，无需根据SomeId切换调用逻辑，交互更简洁
• 类型转换疑虑的解决方案：
  • 安全校验前置：在工厂转换前先做类型检查，比如用is或as关键字判断类型是否匹配，不匹配时抛出明确的业务异常，避免无效转换
  • 自定义模型绑定：在API接收请求阶段，就根据SomeId的值将请求体直接反序列化为对应的具体Content类型，跳过object中转，从根源上减少显式类型转换的需求
  • 封装转换逻辑：将类型转换的细节完全封装在工厂类内部，业务层无需关心转换过程，仅依赖工厂返回的强类型对象进行处理
  • 缓存反射逻辑：如果需要用到反射实现动态转换，可提前缓存反射结果（如Type对象、构造函数或属性访问器），避免重复反射带来的性能损耗

建议 #

如果未来SomeId存在频繁新增的可能，优先选择方案2。通过自定义模型绑定或工厂内的安全校验机制，完全可以将类型转换的风险控制在可控范围内，同时兼顾代码的扩展性和维护性。

内容的提问来源于stack exchange，提问作者Nick Farsi