Ich bin ein erfahrener .Net-Entwickler, der versucht, Python-Code zu schreiben. Bei einem der Projekte, an denen ich mitarbeite, haben wir eine Services-Schicht, die aus einer Reihe von Klassen besteht, die Funktionen abstrahieren, und eine Django-Web-App, die diese in Prozess-Services (die nur Klassen sind) konsumiert.
Ich hatte eine Repository-Schicht erstellt und sichergestellt, dass die gesamte Interaktion mit der Datenbank über die Services-Schicht über dieses Repository erfolgt. Wir haben eine dokumentenorientierte Datenbank und somit haben wir nicht den üblichen objekt-relationalen Dreck. Während einer kürzlichen Code-Überprüfung hat sich ein Entwickler, der angeblich mit Python vertraut ist, davor geäußert und kommentiert, dass dies nicht die Python-Art war, Dinge zu tun. Er bemerkte, dass Python-Entwickler daran gewöhnt sind, eine Sicherungs- und Lösch-Methode für die Objektinstanz selbst zu haben (und das Repository-Muster nicht so oft verwenden), und dies würde Python-Entwickler verwirren, die zu unserem OSS-Projekt beitragen möchten. Python-Entwickler, deine Ansichten? Würdest du verwirrt sein?
Bearbeiten: Dies ist kein Django-Code, sondern Code, der von der Django-App (It in process service layer) aufgerufen wird
Djangos ORM bietet die Methoden save() und delete() für das Objekt. SQLAlchemy hat andererseits eine sogenannte session , zu der Sie Objekte hinzufügen oder löschen.
Beide sind sehr beliebt, also würde ich sagen, dass beide Methoden hinsichtlich der Popularität ungefähr gleich sind. Im Rahmen einer Django-Anwendung ist es jedoch wahrscheinlich vorzuziehen, mit der Django-Konvention zu gehen, es sei denn, Sie haben einen guten Grund, dies nicht zu tun.
Das Beste aus meiner Erinnerung Djangos Modelle beinhalten save() und delete() Methoden, so dass Sie ausschließlich mit Objekten arbeiten können, anstatt mit einem Datenbankverbindungsobjekt zu interagieren. Ich weiß nicht, dass es sofort eine Python-Art ist, Dinge zu tun, aber ich bin mir ziemlich sicher, dass es ein allgegenwärtiges Django-Muster ist.
Wenn mir gesagt würde "Das ist Django-Code", aber der Code weicht von der Art ab, wie Django Dinge macht, könnte das verwirrend sein.
Wiederhole dich nicht selbst. Wenn alle in der Datenbank gespeicherten Daten durch django zugänglich sein sollen (z. B. sind sie in der Datei django models.py definiert); Es gibt ein Django-ORM, das bereits sicher entworfen wurde (keine SQL-Injection) und einfach über save() und delete() auf die Datenbank zugreifen kann. Es gibt auch hilfreiche Wrapper-Funktionen zum Erstellen von Transaktionen (zB @transaction.commit_on_success zum Gruppieren von Aktionen. Sie können das ORM in Python-Skripten außerhalb der laufenden django Web-App verwenden. ZB erstellen Sie ein django-Verwaltungsbefehl oder führen Sie ein Skript aus der django-Shell ( ./manage shell )
Ich stimme definitiv zu, dass eine andere Repository-Ebene Verwirrung stiftet und möglicherweise zu schwerwiegenden Problemen für Leute führt, die Ihre verwenden. Z. B. haben Sie manchmal eine Modellvalidierung, die über die Validierung der Datenbank hinausgeht, und wenn Sie sie außerhalb von django speichern, wird die Validierung niemals ausgeführt. Oder jedes Mal, wenn ein bestimmtes Modell gespeichert wird, sollte zusätzliches Verhalten auftreten (z. B. ein komplementäres Objekt erstellen oder eine Aufgabe generieren), das übersprungen würde, wenn save() nicht aufgerufen wird, sodass die pre_save post_save-Signale niemals generiert werden.
Zugegeben, Sie haben gesagt, das ist eine dokumentenorientierte Datenbank (z. B. mongdb / couchdb), und AFAIK django unterstützt diese Art von NoSQL dbs nicht, also ignorieren Sie, was ich gesagt habe.
Tags und Links python