DRF两种POST请求实现方案选型疑问：初始选哪种更合理？

针对你提出的疑问——初始阶段选方案2保持简洁，还是选方案1为未来扩展留余地，下面是具体分析和建议：

方案1：序列化器内处理创建逻辑 #

# view.py
class ExampleView1(APIView):
    def post(self, request):
        data = request.data
        serializer = CourseSerializer(data=data, context={"request": request}, partial=True)
        if serializer.is_valid(raise_exception=True):
            serializer.save()
            return Response(serializer.data, status=status.HTTP_201_CREATED)

# serializer .create() method
class ExampleSerializer(ModelSerializer):
   def create(self, validated_data):
       user = self.context.get("request").user
       return Course.objects.create(**validated_data, owner=user)

这个方案把关联当前用户为Course的owner这一逻辑放在序列化器的create()方法中，视图只负责数据验证和触发保存，完全符合DRF“序列化器处理数据业务逻辑”的设计思路。

• 优点：逻辑内聚，后续如果在其他视图、脚本或管理命令中复用这个序列化器创建Course，不需要重复编写owner赋值逻辑；未来扩展创建逻辑（比如增加字段校验、关联其他模型）时，只需修改序列化器的create()方法，视图层无需变动，维护成本低。
• 这也是DRF社区更普遍采用的实践方式，为长期维护和扩展预留了空间。

方案2：视图层直接修改请求数据 #

class ExampleView2(APIView):
    def post(self, request):
        data = request.data
        data["owner"] = request.user.pk
        serializer = CourseSerializer(data=data)
        if serializer.is_valid(raise_exception=True):
            serializer.save()
            return Response(serializer.data, status=status.HTTP_201_CREATED)

这个方案把owner字段的赋值逻辑放在视图中，序列化器无需自定义create()，看起来更简洁。

• 缺点：逻辑分散，一旦需要在其他地方复用该序列化器，会漏掉owner字段的赋值；后续如果要调整owner的关联规则（比如需要校验用户权限后再赋值），就得修改所有用到该逻辑的视图，维护起来很麻烦；而且直接修改request.data的做法，也不符合DRF的数据流规范。

结论 #

如果你的项目需要长期维护，或者后续大概率会扩展功能、复用序列化器，优先选择方案1，它的可维护性和扩展性更强，也是社区的通用实践；如果只是临时的简单场景，短期内不会有扩展需求，方案2可以快速实现，但不建议在正式项目中长期使用。

内容的提问来源于stack exchange，提问作者Jože Kuhar