数据校验应在何处进行？Model还是Serializer？

一、将校验逻辑置于数据Model本身 #

优点 #

• 校验和数据定义强绑定，任何写入Model的操作都会触发校验，从根源上避免漏校验，对数据一致性要求高的场景特别靠谱。
• 复用性拉满，不管是API接口、后台管理还是脚本操作，只要碰这个Model，校验规则就自动生效，不用重复写代码。
• 能和ORM的内置能力、数据库约束（比如唯一键、非空）无缝配合，在数据存进数据库前就把非法数据拦下来。

缺点 #

• 容易把Model搞臃肿，要是校验规则复杂或者带业务逻辑，Model就会既要管数据结构又要管业务校验，违反单一职责原则，后期维护起来头疼。
• 没法灵活适配不同输入场景：比如同一个用户Model，前端注册要校验验证码，后台批量导入不用，放Model里就没法区分这两种情况。
• 业务逻辑和数据层绑死，改业务规则就得动Model，牵一发而动全身。

适用场景 #

• 核心数据的基础校验：比如用户手机号格式、邮箱合法性、密码强度，这些是不管啥场景都必须遵守的硬规则。
• 对数据一致性要求极高的系统：比如金融、医疗系统，必须保证任何途径进数据库的数据都符合最基本的规范。
• 小型简单系统：业务逻辑不复杂，Model不会因为加了校验就变得臃肿不堪。

二、将校验逻辑置于独立的Serializer类 #

优点 #

• 职责清晰，Model只管数据定义和存数据库，Serializer专门搞数据校验和格式转换，符合单一职责，代码结构更清爽。
• 灵活性超强，同一个Model可以搞多个Serializer适配不同场景：比如用户注册用带验证码校验的Serializer，资料修改用不带的，互不干扰。
• 好维护好测试，校验逻辑都集中在Serializer里，改规则不用碰Model，单独写单元测试也方便。
• 能处理复杂业务校验：比如判断开始时间早于结束时间、校验优惠券是否有效（要调用外部服务）这类和业务强相关的逻辑，放Serializer里更合适。

缺点 #

• 有漏校验风险：要是绕过Serializer直接操作Model（比如写脚本直接用ORM存数据），校验规则就不起作用，可能让非法数据溜进数据库。
• 可能出现规则重复：多个Serializer要是需要同一套基础校验，要么重复写，要么得抽公共函数，多了点工作量。

适用场景 #

• 多场景API开发：同一个Model要适配不同接口，每个接口的校验规则不一样。
• 复杂业务逻辑的校验：校验涉及业务流程、外部服务调用或者多字段关联判断。
• 前后端分离系统：Serializer作为前后端数据交互的中间层，专门处理输入数据的校验和格式转换。

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