实体类应拆分多少个模型？如何平衡SRP与DRY原则避免代码冗余

1. 拆分模型存在代码重复是否还有必要？ #

非常有必要，现阶段属性重合只是当前需求阶段的巧合，不代表不同场景的模型职责一致：

• 创建操作的ArticleInputModel天生不需要携带Id、CreatedOn、ViewsCount、Comments这类由后端生成、统计的字段，保留这些字段反而会增加恶意参数注入的风险，需要额外做无用字段的校验逻辑。
• 更新操作的ArticleUpdateModel只需要携带必要的待修改字段，CreatedOn、ViewsCount这类不允许修改的字段完全不需要出现在更新模型中。
• 详情展示的ArticleDetailsModel可能还需要额外扩展阅读时长、关联推荐内容等视图专属字段，和入参模型的定位完全不同。

2. SRP和DRY原则如何权衡？ #

你对DRY原则的理解存在偏差：DRY约束的是重复的业务逻辑，而非重复的字段定义。
不同场景的模型即使字段完全一致，对应的校验规则、序列化逻辑、业务绑定逻辑都完全不同，属于完全独立的职责范畴，强行合并模型反而会引入隐式依赖：比如你为了创建场景修改了某个字段的校验规则，很可能意外影响更新、展示场景的正常逻辑，反而带来更高的维护成本。
如果想要减少重复代码，可以通过两种方式实现：

• 用基类封装多个模型共有的字段，不同场景的模型继承基类后扩展自有字段即可
• 用AutoMapper、Mapster这类对象映射工具实现不同模型与实体类的自动赋值，不用手写重复的映射代码

3. 容易忽略的设计要点 #

你目前的思路忽略了以下几个关键设计点：

• 校验规则隔离：不同操作的字段校验逻辑完全不同，比如创建场景不需要校验Id合法性，更新场景必须校验Id是否存在，拆分模型可以独立配置校验规则，不会互相干扰。
• 敏感字段泄露防护：如果复用同一个模型，很容易在接口返回时意外泄露内部字段，比如未公开的统计字段、逻辑字段，拆分模型从定义层面就避免了这类风险。
• 接口契约明确性：拆分后每个接口的入参、出参契约都是明确的，对接、维护时不需要额外说明哪些字段在当前场景无效，降低沟通和维护成本。
• 迭代兼容性：后续需求迭代时不同场景的模型可以独立扩展，比如创建模型新增草稿状态字段、详情模型新增关联推荐字段，都不会影响其他场景的逻辑。

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