Ich muss externe REST-APIs von Django aufrufen. Die externen Datenquellenschemas ähneln meinen Django-Modellen. Ich sollte die Remote-Daten und lokale Daten synchron halten (vielleicht nicht relevant für die Frage)
Fragen:
Danke
BEARBEITEN: für die Leute, die bereit sind, diese Frage zu beantworten: Ich habe die Frage in drei einfachen Fragen von Anfang an aufgeteilt und ich habe bisher gute Antworten erhalten, danke.
> Ich denke, es ist eine Meinung, wo man Webdienste aufrufen kann. Ich würde sagen, verschmutzen Sie Ihre Modelle nicht, weil Sie wahrscheinlich Instanzen dieser Modelle benötigen, um diese Webdienste aufzurufen. Das könnte keinen Sinn ergeben. Ihre andere Wahl ist es, Dinge @classmethod auf den Modellen zu machen, was nicht sehr sauberes Design ist, würde ich streiten.
Der Aufruf aus der Ansicht ist wahrscheinlich natürlicher, wenn der Zugriff auf die Ansicht selbst den Web-Service-Aufruf auslöst. Ist es? Sie sagten, dass Sie die Dinge synchron halten müssen, was auf eine mögliche Hintergrundverarbeitung hinweist. An diesem Punkt können Sie immer noch Ansichten verwenden, wenn Ihre Hintergrundprozesse HTTP-Anfragen ausgeben, aber das ist oft nicht das beste Design. Wenn überhaupt, würden Sie wahrscheinlich Ihre eigene REST-API dafür benötigen, was eine Trennung des Codes von Ihrer durchschnittlichen Website-Ansicht erforderlich macht.
Meiner Meinung nach sollten diese Anrufe in Modulen und Klassen platziert werden, die speziell für Ihre Remote-Anrufe und die Verarbeitung gekapselt sind. Dies macht Dinge flexibel (Hintergrundjobs, Signale, etc.) und es ist auch einfacher, Komponententest. Sie können den Aufruf dieses Codes in den Ansichten oder an anderer Stelle auslösen, aber die Logik selbst sollte sowohl von den Ansichten als auch von den Modellen getrennt sein, um die Dinge gut zu entkoppeln.
Sie sollten sich vorstellen, dass diese Logik für sich allein existieren sollte, wenn es keinen Django gab, und bauen Sie dann andere Teile, die diese Logik mit Django verbinden (zB: Synchronisieren der Modelle). Mit anderen Worten, behalte Dinge atomar.
Ja, dieselben Gründe wie oben, besonders Flexibilität. Gibt es einen Grund, nicht?
Ja, erstellen Sie einfach das Äquivalent einer Schnittstelle. Jede Klasse muss der Schnittstelle zugeordnet sein. Wenn die Felder gleich sind und Sie faul sind, können Sie in Python einfach die Felder, die Sie benötigen, als Konstrukte an den Konstruktor (mit * *kwargs ) ablegen und damit fertig werden, oder die Schlüssel umbenennen, indem Sie einige Konventionen verwenden, die Sie verarbeiten können. Normalerweise baue ich dafür eine Art einfache Data-Mapper-Klasse auf und verarbeite die Django- oder Rest-Modelle in einem Listenverständnis, aber keine Notwendigkeit, wenn die Dinge wie erwähnt zusammenpassen.
Eine weitere verwandte Option zum oben genannten ist, dass Sie Dinge in einer gemeinsamen Struktur in einem Cache wie Redis oder Memcache ablegen können. Es könnte ratsam sein, diese Informationen atomar zu aktualisieren, wenn Sie sich mit "Frische" beschäftigen. Aber im Allgemeinen sollten Sie eine einzige Autorität haben, die Ihnen sagen kann, was eigentlich frisch ist. In Synchronisierungssituationen denke ich, dass es besser ist, das eine oder andere auszuwählen, um die Dinge vorhersehbar und klar zu halten.
Eine letzte Sache, die Ihr Design beeinflussen könnte, ist, dass es per Definition schwierig ist, Dinge synchron zu halten. Syncs neigen dazu, sehr anfällig für Fehler zu sein, so dass Sie eine Art von dauerhaften Mechanismus wie eine Task-Warteschlange oder Job-System für Wiederholungen haben sollte. Gehen Sie beim Anrufen einer Remote-REST-API immer davon aus, dass Aufrufe aus verrückten Gründen wie Netzwerk-Hicups fehlschlagen können. Beachten Sie auch Transaktionen und Transaktionsverhalten beim Synchronisieren. Da dies wichtig ist, weist es erneut auf die Tatsache hin, dass Sie, wenn Sie diese Logik direkt in eine Ansicht einfügen, wahrscheinlich Probleme haben werden, sie im Hintergrund zu verwenden, ohne die Dinge trotzdem ein wenig zu abstrahieren.
Was ist der logischste Ort, an dem externe Web-Services aufgerufen werden: über eine Modellmethode oder über eine Ansicht?
Idealerweise sollten Ihre Modelle nur mit der Datenbank kommunizieren und keine Ahnung haben, was mit Ihrer Geschäftslogik passiert.
Sollte ich den Code, der die Remote-API aufruft, in externe Module einfügen, die dann von den Views aufgerufen werden?
Wenn Sie von mehreren Modulen auf sie zugreifen müssen, dann ist es sinnvoll, sie in ein Modul zu platzieren. Auf diese Weise können Sie sie effizient wiederverwenden.
Kann die Datenquelle bedingt ausgewählt werden? Das bedeutet, dass die Daten von der REST-API oder den lokalen Modellen abhängig von ihrer "Frische" präsentiert werden?
Natürlich ist es möglich. Sie können einfach implementieren, wie Sie Ihre Daten auf Anfrage abrufen. Der effizienteste Weg besteht jedoch darin, diese Logik zu vermeiden und nur Ihre lokalen Daten mit entfernten Daten zu synchronisieren und die lokalen Daten in den Ansichten anzuzeigen.
Tags und Links python django rest django-models django-views