[PYTHON] Überlegungen zum Design von Django REST Framework + Clean Architecture

Django REST Framework + saubere Architektur Überlegungen zum Design

Einführung

Mit dem jüngsten Aufstieg der KI denke ich, dass die Auswahl, mit Python für die Entwicklung neuer Systeme zu bauen, zugenommen hat. Wenn es darum geht, neue Webdienste in Python zu schreiben, besteht die Hauptoption meiner Meinung nach darin, eine REST-API mit einem Framework wie React oder Vue.js für das Front-End und Django oder Flask für das Back-End bereitzustellen. Mit einer einfachen Konfiguration macht es das Django REST Framework einfach und unkompliziert, einen API-Server zu erstellen. Wenn es jedoch etwas kompliziert wird, wird es schnell chaotisch, wenn Sie nicht richtig über die Architektur nachdenken. ~~ In dem Fall, in dem ich eingetreten bin, ist dies bereits Chaos und Chaos. .. .. ~~ Soweit ich recherchiert habe, gibt es keinen Artikel über die Kombination von Django REST Framework + Clean Architecture, daher werde ich dies in diesem Artikel sowie in meiner eigenen Studie und Zusammenfassung der Gedanken berücksichtigen. ~~ Es ist ziemlich schmerzhaft, deshalb möchte ich es mit den hier zusammengefassten Inhalten vorstellen. ~~ Bitte kommentieren Sie, wenn Sie ein gutes Design haben.

Dieses Mal erwägen wir, Projekt und Anwendung (später beschrieben) auszuschließen. Auch Routing, ViewSet, ModelManager usw. werden nicht berücksichtigt.

Da es sich nur um Bilder und Sätze handelt, habe ich versucht, ein Beispiel zu implementieren. Beispielcode finden Sie hier [https://github.com/ryoutoku/django_rest_clean_architecture]. Basierend auf dem Modell des Django-Tutorials werde ich versuchen, nur den POST der Frage zu implementieren. (Da ich jedoch nicht so viel über die Geschäftslogik nachdenken konnte, ist es nur eine Implementierung, die die POST-Verarbeitung nutzlos überflüssig macht.)

Konfiguration und Probleme des Django REST Framework

Django selbst ist ein Framework, das auf der Idee basiert, dass ein Projekt mehrere Anwendungen und MVT (Model, View, Template) enthält. Im Django REST Framework gibt es keine "Vorlage" und mehr "Serializer".

Unten finden Sie ein Diagramm der Architektur und der Rollen des Django REST Framework. Für die CRUD-Verarbeitung für ein "Modell" (1 Datenbanktabelle) ist "Ansicht" - "Serializer" - "Modell" im Grunde 1 zu 1 zu 1 und kann einfach erstellt werden.

Bei Webdiensten auf Unternehmensebene wird bei Ausführung der REST-API die Logikverarbeitung gemäß einigen Geschäftskenntnissen, Regeln und Beurteilungen ausgeführt, sodass nur selten eine 1-Tabellen-CRUD-Verarbeitung ausgeführt wird. Wenn Sie jedoch mit der Implementierung beginnen, ohne die Architektur gründlich zu berücksichtigen, führt die vom Django REST Framework bereitgestellte Architektur zu Chaos. .. ..

Für mich sind die folgenden zwei Punkte große Probleme, die eher chaotisch sind. Ist es nicht im Grunde ein Rahmen, der leicht gegen das Prinzip der Einzelverantwortung verstößt? Ich fühle, dass.

Problem 1. "Ansichten" sind in der Regel kompliziert (es handelt sich in der Regel um Fat Contoller).

Dies ist ein Problem namens Fat Controller, bei dem die Logik in "Ansichten" geschrieben ist. Es ist ein Problem, das häufig auftritt, wenn ein Anfänger oder jemand, der sich nicht für Architektur interessiert, es schafft.

Wenn es im Django REST Framework einfach ist, gibt es fast keine Implementierung der CRUD-Verarbeitung, wie unten gezeigt.

models.py

from django.db import models

class Question(models.Model):
    #Angebot ORM
    question_text = models.CharField(max_length=10)
    pub_date = models.DateTimeField('date published')

serialzers.py

from .models import Question
from rest_framework import serializers

class QuestionSerializer(serializers.ModelSerializer):
    # data <->Bietet Modellkonvertierung
    class Meta:
        model = Question
        fields = '__all__'
        # data <->Modell Definieren Sie das Modell und das Feld, die konvertiert werden sollen

views.py

from rest_framework import viewsets
from .models import Question
from .serializers import  QuestionSerializer

class QuestionViewSet(viewsets.ModelViewSet):
    #REST-API I./Angebot O.
    queryset = Question.objects.all()
    serializer_class = QuestionSerializer

    #Weil die Vererbungsquelle ModelViewSet eine Funktion definiert, die eine API für die CRUD-Verarbeitung ist.
    #Sie müssen keine Methode erstellen

Die CRUD-Verarbeitung wird auf der Seite des Django REST Framework bereitgestellt und ausgeblendet. Wenn Sie beispielsweise beim Speichern von Daten (POST) eine Logik einbeziehen müssen, können Sie diese einfach in Ansichten schreiben -> "Vorerst zu" Ansichten "(Controller) hinzufügen". Ist es nicht oft so, dass Sie verschiedene Dinge in .py schreiben?

Wenn Sie keine neue Klasse schreiben, anstatt sie solide zu schreiben, werden Sie zum Fat Controller.

Problem 2. Geschäftskenntnisse lassen sich leicht in "Serialisierer" und "Modelle" verteilen

Da Serializer eine Validierung bietet, werden Sie sich fragen, wo die Validierung implementiert werden soll (nicht auf der Ebene der Geschäftskenntnisse), z. B. die oberen und unteren Wertegrenzen und das Format der Zeichenfolgen. Wenn Sie die Logik so einfügen, dass sie in "Serializer" implementiert ist, weil eine Validierung bereitgestellt wird, werden "Seliarizer" mehreren Verantwortlichkeiten zugewiesen. Was ist die Validierung von "Serialisierern", wenn sie in "Modellen" implementiert sind? Es wird werden. Wenn Sie mit einer großen Anzahl von Personen entwickeln, wird die Logik verstreut, es sei denn, Sie implementieren sie mit einer einheitlichen Idee. .. ..

Wenn Sie nicht darüber nachdenken, was und wo implementiert werden soll, kann dies zu Chaos führen.

Ursachen für persönliche Probleme

Ich denke, der Grund, warum Serializer eher chaotisch ist, ist, dass es zu viele Funktionen bietet (zu gut). Insbesondere frage ich mich, ob die Ursache wie folgt ist.

-Serializer.save () speichert den entsprechenden model-Datensatz (abhängig von der ererbenden Serializer-Klasse)

• Weil es entweder mit model oder serializer gespeichert werden kann --Serializer verfügt über eine Validierungsfunktion, und die Validierung kann angepasst werden. -> Ich möchte Geschäftswissen in serializer.validation () einfügen (weil es Validierung heißt)

Voruntersuchung 1. Design / Implementierung einer anderen Person

Ich habe "Django Rest Framework Logic" gegoogelt und es kam zuerst heraus diese Seite ), Es steht geschrieben, dass die Logik in "Serialisierern" gesammelt wird. Es gibt jedoch ein Problem mit dem Test. Diese Person ist so geschrieben, dass sie in "Ansichten" geschrieben wird, aber ich bin der Meinung, dass die Geschäftslogik wahrscheinlich verstreut ist. .. .. ..

Vorläufige Umfrage 2. Unterstützung zwischen Django REST Framework und Clean Architecture

Unten sehen Sie ein Diagramm der Korrespondenz zwischen dem Django REST Framework und Clean Architecture, die ich interpretiere. Die linke ist die ursprüngliche Komposition, die rechte ist die [übliche Abbildung] von Clean Architecture (https://blog.cleancoder.com/uncle-bob/images/2012-08-13-the-clean-architecture/CleanArchitecture.jpg). Ich habe versucht, es abzubilden. Die linke ist die Referenz und die rechte ist die Zuordnung.

In diesem Zusammenhang gibt es keine entsprechende xxx-Geschäftsregel. .. ..

Django REST Framework + Studie zum Design sauberer Architektur

Design

Basierend auf dem oben Gesagten haben wir es wie folgt entworfen. Oder besser gesagt, ich habe wahrscheinlich auf [hier] verwiesen (https://qiita.com/MinoDriven/items/3c7db287e2c66f36589a).

Ich habe es grob mit der folgenden Richtlinie entworfen. Offensichtlich ist die Domänenlogik nicht in "Ansichten", "Serialisierern" und "Modellen" geschrieben. Umgekehrt wird für diejenigen, die keine Domänenlogik enthalten, angenommen, dass sie gemäß dem Django REST Framework verwendet werden.

Verhalten

Das Verhalten beim Aufrufen der REST-API wird unten beschrieben (einige sind nicht implementiert).

• Beim Ausführen der Abfrage (GET)

--Verwenden Sie die von Django REST Framework bereitgestellten Funktionen unverändert

• Wenn Sie Daten aus anderen Ressourcen als Django abrufen, definieren Sie sie mit "SerializerMethodField" usw. auf der "Serializer" -Seite.

• Bei Ausführung des Befehls: Keine Geschäftslogik ver

--Validieren Sie Werte mit Aggregate und DomainObject in validate () of serializer

• Beim Ausführen des Befehls (POST / PUT / PATCH / DELETE): Mit Geschäftslogik ver

1. views übergibt application_services von serializer an dict von Daten als Argument
2. application_service erstellt und verarbeitet Aggregate basierend auf dem Argument dict.

• Verwenden Sie "IXXXReader", um "Aggregat" aus DB-Daten zu generieren --Wenn Sie Daten speichern, erstellen Sie "Aggregat" basierend auf dem Argument "Dikt", übergeben Sie es an "IXXXWriter" und speichern Sie es.
• Gibt ein antwortbewusstes "Diktat" zu "Ansichten" zurück

3. Kehren Sie mit serializer zurück, um eine Antwort zu erhalten, die auf dict basiert, das von application_services erhalten wurde

Zusammenfassung und Eindrücke

Unten finden Sie eine Zusammenfassung meiner Gedanken beim Forschen und Entwerfen.

In Bezug auf die Umsetzung

• Ich denke, dass die I / F auf der Seite der Schnittstellenadapter und der Seite der XXX-Geschäftsregeln einfach war und eine logische Aufteilung möglich war.
• Aber es gibt noch mehr Dateien und Module ――Es kann bei Menschen, die Wert auf Leistung legen, unbeliebt sein
• Die Gewohnheit von "Daten" und "validierten_Daten" (insbesondere "DateTimeField") von "Serializer" ist stark.
• Ich bin süchtig danach, "str" für "data" und "datetime" für "validated_data" zurückzugeben.
• Ich möchte die Implementierung etwas einfacher machen, z. B. "DomainObject", oder es einfacher machen.
• Es ist besser, "NamedTuple" zu verwenden oder die Eigenschaft zu diktieren, um die Erstellung und Verwendung zu vereinfachen.
• Abhängig vom Inhalt von Query, Command und Command gibt es Implementierungsmuster nur für REST Framework und Implementierungsmuster, die Clean Architecture berücksichtigen.
• Muster sind in der Regel chaotisch, daher ist ein gemeinsames Verständnis innerhalb des Projekts erforderlich.
• In Python ist die Definition der Schnittstelle nicht sehr gut.

In Bezug auf den tatsächlichen Betrieb

Wenn Sie einen API-Server erstellen (oder einen URI entwerfen) möchten, ist es meiner Meinung nach besser, die GraphQL- und REST-API mit der folgenden Richtlinie ordnungsgemäß zu verwenden.

• Bereitgestellt von GraphQL for Query
• Aus Sicht der Benutzeroberfläche ist es für REST-APIs schwierig, nur die erforderlichen Daten bereitzustellen. Wenn Sie versuchen, REST-APIs für jede Benutzeroberfläche bereitzustellen, erhöht sich die Anzahl der APIs.
• Da für die Abfrage keine Validierung erforderlich ist, ist GraphQL, das flexibel bereitgestellt werden kann, möglicherweise besser geeignet.
• Bereitgestellt von der REST-API für Command
• Da es den Anschein hat, dass häufig Geschäftslogik in jeden Befehl involviert ist, ist es besser, die API und ihre Parameter explizit zu bestimmen, als flexible I / F bereitzustellen.

Schließlich

Ich bin mir auf der aktuellen Seite sicher "Es ist einfacher und verständlicher, wenn Sie die Logik in" Ansichten "einfügen (in einer Methode sind über 200 Logikzeilen implementiert)." "Wenn Sie eine Klasse vergeblich machen, wird die Leistung ... (Es scheint, dass die Leistung nicht gemessen wird)" Ah ... ich weiß nicht ...

Verweise

https://medium.com/@amarbasic4/django-rest-framework-where-to-put-business-logic-82e71c339022 https://isseisuzuki.com/it/django-rest-framework-concept/ https://qiita.com/MinoDriven/items/3c7db287e2c66f36589a https://blog.cleancoder.com/uncle-bob/2012/08/13/the-clean-architecture.html https://blog.tai2.net/the_clean_architecture.html