DRF嵌套对象POST参数设计合理性及view与serializer执行先后咨询

请求调用链路优先级 #

DRF处理POST请求不存在“二选一优先调用”的对立关系，完整执行顺序是固定的：

1. 请求首先经过路由匹配到对应View，依次执行权限校验、访问频率限制、请求报文解析这些和HTTP协议强相关的步骤
2. 所有前置校验通过后，才会实例化绑定在View上的序列化器，把请求携带的结构化数据塞给序列化器做字段层面的校验
3. 序列化器校验无报错后，才会执行对象保存逻辑完成数据库写入

简单来说：View是请求的唯一入口，序列化器是数据处理的核心载体。正常开发中View里不要塞业务转换逻辑，只管处理和请求相关的事；所有和模型数据相关的校验、转换、入库逻辑，全部下沉到序列化器实现。

实现方案的最佳实践判定 #

• 你调研的两类方案里，把关联处理逻辑放在序列化器层重写对应方法的写法是完全符合DRF设计思路的，直接把逻辑硬编码在View的create方法里的写法属于需要规避的反模式。原因很现实：逻辑下沉到序列化器之后，不管是接口触发创建、Django admin后台触发创建、还是脚本批量导入触发创建，都会自动复用这套“根据文件名匹配File对象”的逻辑，不会出现代码重复、逻辑漏写的问题；如果把逻辑写在View里，后续新增其他创建入口时，很容易忘掉加文件名匹配的步骤，导致入库数据出错。
• 针对你现在的需求，甚至不需要拆分读写序列化器、重写整个create方法，更轻量的实现方式是自定义一个关联字段，复用现有外键字段的校验逻辑：

  class FileNameRelatedField(serializers.PrimaryKeyRelatedField):
      def get_queryset(self):
          return File.objects.all()
  
      def to_internal_value(self, data):
          # 入参是文件名字符串，从数据库匹配对应File对象
          try:
              return File.objects.get(name=data)
          except File.DoesNotExist:
              raise serializers.ValidationError("未找到匹配名称的文件记录")
  
      def to_representation(self, instance):
          # 响应输出时直接返回文件名称，不用暴露关联ID
          return instance.name
  

  主业务序列化器里直接替换原来的整数外键字段就行：

  class CommentRecordSerializer(serializers.ModelSerializer):
      file = FileNameRelatedField()
      class Meta:
          model = CommentRecord
          fields = ["comment", "priority", "file"]
  

  这种写法的侵入性极低，同一个字段同时搞定“入参传名字、自动存关联ID”和“出参返回名字”的双向转换，比拆分读写序列化器的实现代码量少很多。
• 关于“是否必须传完整嵌套的关联对象”的疑问：DRF从来没有强制要求创建接口必须传完整嵌套的关联对象。如果只是关联已经存在的File记录，不管是传对象PK、传文件唯一名称、还是传其他能定位记录的业务唯一标识，都是合理的交互设计；只有当接口需要同时创建新的File记录的时候，才需要用嵌套序列化器传完整的关联对象结构，为了凑所谓的“嵌套规范”硬传完整对象，反而会平白增加前后端的传输和处理成本。

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