是否应拆分加载与保存模型？表单编辑场景下的模型设计疑问

结论：拆分是合理的，且利大于弊 #

1. 遵循职责单一原则 #

• Person作为展示模型，专注于承载表单显示所需的所有数据（包括仅用于展示的JobName）；
• PersonToSave作为命令模型，仅包含保存操作必需的字段（Id/Name/JobId），职责清晰，避免无效数据流入保存逻辑。

2. 消除字段模糊性 #

如果复用同一个Person类，后续业务流程中很容易出现困惑：

• 哪些字段是保存时必填的？哪些是只读的展示字段？
• 新开发人员可能误将JobName这类展示字段传入保存方法，或者在其他查询场景中遗漏必要字段。
  拆分后每个模型的用途一目了然，从根源上减少这类误解和错误。

3. 提升扩展性 #

当业务复杂度提升时：

• 展示模型可以轻松新增更多显示用字段（如部门名称、入职日期），不会影响保存逻辑；
• 命令模型可以独立添加校验规则（如JobId格式验证）、新增保存专属字段，无需修改展示模型的结构。
  这种隔离性能避免修改一处引发全局问题。

关于“是否过于复杂”的疑问 #

初期多一个类看似增加了工作量，但长远来看是降低维护复杂度：

• 每个模型的逻辑更简洁，定位问题更高效；
• 可以用映射工具（如AutoMapper）简化模型转换，比如从Person生成PersonToSave只需一行代码，无需手动赋值：

var personToSave = _mapper.Map<PersonToSave>(person);

额外建议 #

可以引入DTO分层思想，明确区分查询DTO（用于数据展示）、命令DTO（用于数据操作），让整个系统的模型职责体系更清晰，团队协作效率更高。

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