反序列化/序列化DRF

Question

我有兴趣了解以下哪种模式更符合 SOLID 原则。

假设我们在 DRF 中有一个

class CreateView(generics.CreateAPIView)

。

选项 1：用于序列化/反序列化的单个序列化器

from rest_framework import serializers

class MySerializer(serializers.Serializer):
    field1 = serializers.CharField())

    def to_representation(self, instance):
        return {
            'field1': instance.field1,
        }

选项2： 创建 2 个类

1. MySerializer

   （序列化我想要创建的响应并传递给

   response.data

   ）

2. MyDeserializer

   （反序列化我的数据/对传入的数据进行清理/验证

   request.data

   ）

Answer 1

我对 SOLID 原则不是很有经验；事实上，我目前正在阅读 Robert C. Martin 所著的《干净的建筑》一书。 但我习惯在不同的项目（电子商务、移动应用程序和业务工具的后端）中使用 Django 和 Rest 框架进行开发。 我想尝试一个答案。我邀请大家纠正自己并添加任何澄清。

单一责任原则：在不同视图之间共享的序列化器（甚至对于在不同方法中使用它的同一视图，如 get、post、patch）不遵守此原则。一般来说，每个视图（或同一视图的每个方法）都是为了做不同的事情。因此，如果视图中的更改需要支持共享序列化器中的新字段，则必须更改每个视图（或每个方法）（必须在每个方法中处理新字段，否则这可能会导致错误或至少优化问题）。为了尊重这一原则，针对每个目的使用不同的序列化器类似乎是更好的选择。

开放-封闭原则：我对这一原则的理解是这样的：创建一个序列化器类作为公共基础，然后针对每种需要创建一个继承自第一个序列化器的特定序列化器（在您的情况下，一个用于读取，另一个用于写入） 。因此，如果您为同一视图的 get() 和 post() 方法共享唯一的序列化器类，则不遵守此原则。

里氏替换原则：关于读取和创建对象的类的具体示例，我不知道该说什么。当游戏中只有一个职业时，这些原则似乎并不适用。我思考你的观点的演变。想象一下，将来您必须实现对象创建的新版本。并且您必须保持当前版本不变。在新版本中，您必须添加一些用于创建对象的必填字段。在这种情况下，您可以使用当前序列化器的新子类来实现新版本。然后 LSP 就会受到尊重。

接口隔离：当您继承 django Rest Framework 基 ModelSerializer 类时，您的类以所有包括方法开始：create()、update()、delete()...但也许您只想使用其中一个或不使用其中一个。我不知道如何避免这种情况以尊重接口隔离。

依赖倒置原则：不知道你的情况与依赖倒置原则有何关系

我希望这个想法的开始是有帮助的。 这是给我的。 谢谢你提出这个问题。