CODEWITHSUNDEEP
djangoserializationdeserializationsolid-principlesdjango-rest-auth
Konstanitnos Schoinas
Konstanitnos Schoinas

Reputation: 159

Deserialization/Serialization in Django rest framework and the SOLID principles

I am interested in understanding which pattern of the below is more aligned with the SOLID principles.

Say We have a class CreateView(generics.CreateAPIView) in Django Rest Framework.

Option 1: Single Serializer for serialization/deserialization

from rest_framework import serializers

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

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

Option 2: Create 2 classes

  1. MySerializer ( serialize the response I want to create and pass to the response.data )
  2. MyDeserializer ( deserialise my data / perform sanitisation/validation of the incoming request.data )

Upvotes: 1

Views: 109

Answers (1)

0urz4g
0urz4g

Reputation: 463

I'm not very experienced in the SOLID principles ; Indeed I'm currently reading the book "clean architecture" by Robert C. Martin. But I use to develop on Django and rest framework in different projects (backend for e-commerce, mobile app and business tools). I want to try an answer. I invite everyone to correct myself and add any clarifications.

Single-responsibility principle : a serializer shared between different views (or even for the same view using it in different methods, like get, post, patch) does not respect this principle. Generally, each view (or each method of the same view) is for doing something different. So if a change in a view require to support a new field in the shared serializer, every view (or every method) has to be changed (the new field has to be handled in each method, otherwise this could lead to bugs or at least optimization problems). To respect this principle, it seems to be a better choice to use a different serializer class for each purpose.

Open–closed principle : I understand this principle as this : create one serializer class as a common base, and, for each need, create a specific serializer which inherits from the first (in your case one for reading and another one for writing). So If you share a unique serializer class for both methods get() and post() of the same view, this principle is not respected.

Liskov substitution principle : about your specific example of a class which reads and creates objects, I don't know what to say. Theses principles don't seems to be applicable when there is only one class in the game. I think about the evolution of your view. Imagine in the future you have to implement a new version of the creation of your objects. And you have to keep the current version as it is. In the new version, you have to add some mandatory fields for the creation of the object. In this situation, you can implement a new version using a new subclass of your current serializer. The LSP is then respected.

Interface segregation : when you inherit from django rest framework base ModelSerializer class, your class starts with all the including methods : create(), update(), delete()... But maybe you want to use only one or none of them. I don't know how to avoid that in order to respect the interface segregation.

Dependency inversion principle : I don't know how your situation is concerned by the dependency inversion principle

I hope this beginning of thinking was helpful. It was for me. Thank you for this question.

Upvotes: 0

Related Questions