Django ist als leistungsstarkes Webanwendungs-Framework in den letzten Jahren immer beliebter geworden. Immer mehr Python-Entwickler investieren in Django, aber auch aufgrund der zahlreichen Probleme mit Django-Inhalten, wenn jeder Als jemand Django zum ersten Mal betritt, fühlt er sich immer ein wenig „ein bisschen überwältigt“ und weiß nicht, wo er anfangen soll. Oder Sie sind nach einem ersten Verständnis immer noch nicht sicher, ob der aktuelle Ansatz elegant ist, wie Sie das Projekt organisieren und wie Sie den Code wiederverwendbar machen können.
Eine gute Projektstruktur ist die halbe Miete.
Standardmäßig sieht die von Django generierte Projektstruktur ungefähr so aus:
Da die Anzahl der Anwendungen im Projekt weiter zunimmt, nehmen auch die Pakete im lokalen Stammverzeichnis weiter zu Da die Anzahl der Dateien zunimmt, wird die Wartung immer schwieriger. Daher müssen wir einen klaren Plan für das gesamte Projekt haben und jede Datei angemessen platzieren.
Wenn das Projekt klein ist und Sie nicht vorhaben, die Anwendung auf verschiedene Weise wiederzuverwenden, können Sie die folgende Methode in Betracht ziehen:
Der Ordner venv speichert die virtuelle Umgebung des Projekts. Dies ist nicht erforderlich und kann woanders platziert werden.
Die Datenbank-App wird speziell zum Speichern von Modellen, zum Verwalten von Befehlen und einigen in Vorlagen verwendeten benutzerdefinierten Filtern verwendet. Sie wird im Projektstammverzeichnis gespeichert.
Dokumente und Protokolle speichern projektbezogene Dokumente bzw. Protokolldateien, die zur Laufzeit generiert werden.
static speichert statische Dateien wie css/js/img/font usw.
utils speichert Toolfunktionen, im Projekt verwendete Klassen und einige gängige Module wie Logger usw.
templates speichert Vorlagendateien oder Vorlagen, die von mehreren Vorlagen geerbt wurden, und werden zur einfacheren Wartung mit Namen wie „base“ abgelegt. Die übrigen Vorlagen werden in Ordnern mit entsprechenden Anwendungsnamen abgelegt.
Das Webverzeichnis speichert alle Anwendungen. Wenn es viele Anwendungen gibt, können diese zur Planung in mehrere Pakete unterteilt werden.
Im Modellmodulteil befassen wir uns hauptsächlich mit der Zuordnung von Daten zu Klassen. Unter normalen Umständen werden die jeder Tabelle entsprechenden Klassen in einer separaten Datei abgelegt und die entsprechenden Klassen werden abgelegt in models/__init__.py Die Klassen werden der Reihe nach importiert, sodass sie bei Verwendung an anderen Stellen über „database.models import xxxx“ importiert werden können. Beim Benennen der Klassen wird empfohlen, den Namen des Projekts hinzuzufügen Beispiel: Der Name meines Projekts hier ist Cherry, dann sind alle Klassen CherryLeaks usw., es wird auf einen Blick klar sein, während des Reivew-Codes und des Schreibprozesses, wenn man weiß, dass diese Klasse Daten darstellt.
Es wird empfohlen, einen separaten Manager für Modelle hinzuzufügen und entsprechende Methoden zu implementieren, um wiederholte Vorgänge zu vermeiden.
Darüber hinaus gibt es einige Vorschläge, die je nach tatsächlicher Situation ausgewählt werden können:
Es wird nicht empfohlen, Typen wie Fremdschlüssel zu verwenden.
Fügen Sie die Felder is_deleted,created_time,Updated_time zu jeder Tabelle hinzu.
Machen Sie es gut Verwendung von Indizes
Der größte Teil der Geschäftslogik sollte im Ansichtsteil platziert werden, und dieser Teil sollte den Kern bilden. Auch hier empfiehlt es sich, alle Views mit ähnlichen Funktionen in derselben Datei abzulegen. Um die zukünftige Wartung und Entwicklung zu erleichtern, sollte diese Datei in einem Paket mit dem Namen „controller“ oder „view“ abgelegt werden. Beispielsweise wird die Verarbeitung des projektbezogenen Routings vollständig in controller/project.py abgelegt.
Verwenden Sie lieber einige der integrierten View-Klassen von Django, z. B. ListView, TemplateView usw. Wenn Sie View selbst implementieren müssen, wird empfohlen, die klassenbasierte Ansicht zu verwenden, um verschiedene Anforderungsmethoden in verschiedene Methoden zu kapseln und so die zukünftige Wartung zu erleichtern .
Für Vorlagendateien ist es am besten, verschiedene Seiten und Funktionen in verschiedene Vorlagendateien zu schneiden und sie in Ordnern unter dem Namen „Anwendung“ zu speichern, damit sie bei späterer Wartung schnell abgerufen werden können entsprechende Vorlagendatei.
Darüber hinaus wird dringend empfohlen, die Vorlagenvererbungsfunktion zu verwenden. Alle Seiten werden von der übergeordneten Vorlage geerbt und zum Erweitern der Seite werden verschiedene Blöcke verwendet. Der Blockname jeder Position ist in der übergeordneten Vorlage definiert abdecken. Es wird empfohlen, für jeden Block einen gängigen und kurzen Namen zu verwenden, z. B.: Seitenleiste, Skript, Kopfzeile, Hauptinhalt, Seitentitel, Seitenbeschreibung usw.
Für allgemeine Funktionen, wie z. B. Kommentarfelder, können Sie erwägen, diese in einer separaten Datei zu speichern und sie bei Bedarf über {% include 'filename.tpl.html' %} zu laden. Es ist zu beachten, dass Sie die Anweisungen „extends“ und „include“ in einem Block verwenden müssen, wenn Sie sie gleichzeitig verwenden müssen, da sie sonst ungültig sind. Die folgenden Beispiele sind ungültig:
sollte wie folgt verwendet werden:
Die Flexibilität der Python-Sprache lässt uns beim Schreiben von Code manchmal den Parametertyp oder Rückgabetyp einer bestimmten Methode vergessen. In diesem Fall müssen wir docstring verwenden, um klare Informationsanmerkungen für jede Methode bereitzustellen, damit andere sie entwickeln und verwalten können. Wenn Sie PyCharm verwenden, können Sie über diesen Link eine Dokumentzeichenfolge für die automatische Vervollständigung schreiben.
In vielen Fällen müssen unsere Methoden mehrere Werte an den Aufrufer zurückgeben oder über JSON zum Front-End zurückkehren. Wenn Daten zufällig zurückgegeben werden, führt dies zu Verwirrung in der Entwicklung Am Ende wissen wir nicht, was die Methode zurückgibt.
Ein besserer Ansatz besteht darin, sich auf das Rückgabeformat zu einigen. Um zum Aufrufer zurückzukehren, geben Sie einfach ein Tupel zurück und schreiben Sie die Bedeutung jedes Werts in die Dokumentzeichenfolge. Zusätzlich zur Rückgabe von Ergebnissen müssen wir manchmal einen Fehler zurückgeben, um anzugeben, ob während der Datenverarbeitung ein Problem oder eine Ausnahme aufgetreten ist. Im Allgemeinen stehen mehrere Methoden zur Verfügung:
Auslösen einer Ausnahme durch raise
Zurückgeben über mehrere Rückgabewerte, z. B. err, result = func()
Zurückgeben über ein Attribut in der Klasse, z. B. example = Class( ) ; err = example.error_message
Diese drei Methoden haben alle Vor- und Nachteile und müssen entsprechend der tatsächlichen Situation des Projekts ausgewählt werden, sie muss im gesamten Projekt konsistent sein Mischen Sie sie nicht so weit wie möglich.
Damit JSON an das Frontend zurückgegeben wird, muss es etwas komplizierter sein. Es müssen mindestens 2 bis 3 Felder zurückgegeben werden:
Code ist der Statuscode durch diesen Anruf zurückgegeben werden, der entsprechend der tatsächlichen Situation vereinbart werden kann. Bei der Nachricht handelt es sich um eine leicht verständliche Meldung des Statuscodes, die von Entwicklern zum Debuggen und zur Bereitstellung von Benachrichtigungen an Benutzer verwendet werden kann. Daten sind die tatsächlich zurückgegebenen Dateninformationen. In vielen Fällen wird dieses Feld möglicherweise nicht benötigt. Das spezifische Feldformat muss basierend auf der tatsächlichen Situation erneut vereinbart werden.
Elegantes und einfaches Routing sichert die Projektqualität und reduziert die Wartungskosten.
Django verfügt über ein leistungsstarkes Routing-System und einen Routing-Algorithmus, der verschiedene Anforderungen im Unternehmen erfüllen kann, und die Konfiguration ist flexibel und einfach. Jede Routing-Konfigurationsdatei ist eine Zuordnung von URL-PFAD zu Funktion/Klasse. Alles kann selbst eingerichtet werden, ohne irgendwelchen Rahmenbedingungen oder anderen Einschränkungen zu unterliegen. In diesem Abschnitt der Dokumentation finden Sie Informationen zu den Anforderungsrouting-Strategien von Django.
Beim Konfigurieren von Routen können Sie einige Variablen zur späteren einfacheren Verwendung in spitze Klammern setzen. Einige „Pfadkonverter“ können in spitzen Klammern verwendet werden, um Variablentypen wie str, int, slug, uuid, path anzugeben. Eine vollständige URL-Routing-Datei sieht so aus:
Darüber hinaus können Sie über re_path auch einen regelmäßigen Abgleich in der Route festlegen:
Manchmal möchten Sie möglicherweise eine Standardroute hinzufügen, zum Beispiel Gibt beim Zugriff auf /blog/ eine Standardseite zurück und gibt beim Zugriff auf /blog/page
Als Wenn das Projekt weiter wächst, wird die Anzahl der verwendeten Routen weiter zunehmen. Daher bietet Django einen Mechanismus zur Routeneinbindung, der uns die Organisation von Routen in verschiedenen Apps erleichtert. Schauen wir uns ein einfaches Beispiel an:
In diesem Beispiel werden alle Routen, die community/* anfordern, zur Analyse an aggregator.urls übergeben. Ebenso werden alle Anfragen für contact/* an einen anderen übergeben 1. Das Routing-Modul übernimmt dies. Wenn Sie nicht so viele Anwendungen in Ihrem Projekt haben und dennoch das Routing über Include verwalten möchten, können Sie die folgende Methode verwenden:
Im Allgemeinen unser Each Das Django-Projekt besteht aus mehreren Apps. Wenn alle App-Routen in URLCONF_ROOT abgelegt werden, wird die Pflege dieser Datei mit der Zeit immer schwieriger und sie wird sehr verwirrend. Routen mit demselben Namen können in verschiedenen Apps verwendet werden, was zu Konflikten führen kann. Um diese Probleme zu lösen, können wir „Routeneinschluss“ und „Namespace“ verwenden. Insbesondere wenn Sie eine App verwalten, die wiederverwendet werden kann, ist der Namespace besonders wichtig, um die Einzigartigkeit der Route sicherzustellen.
Normalerweise gibt es zwei Arten von Namespaces: Anwendungs-Namespace und Instanz-Namespace. Beispielsweise stellt admin:index die Indexroute des Admin-Namespace dar. Weitere Informationen zu diesem Teil finden Sie unter: Offizielle Dokumente
Anwendungsnamespace ist einfacher zu verstehen. Er bezieht sich auf den Namespace auf Anwendungsebene. Er ist im Allgemeinen wie folgt organisiert:
Der Instanz-Namespace bezieht sich auf den Namespace auf Instanzebene, der häufig verwendet wird, wenn eine App mehrmals instanziiert wird. Um die einzelnen Instanzen zu unterscheiden, muss der Instanz-Namespace eingeführt werden. Schauen wir uns das Beispiel in der offiziellen Dokumentation an:
Sie können sehen, dass die beiden Routen „author-polls“ und „publisher-polls“ tatsächlich dasselbe enthalten route , es wird jedoch ein anderer Namespace angegeben, nämlich der Namespace auf Instanzebene, also der Namespace des Objekts, auf das gerade zugegriffen wird. Unterschiedliche Benutzeridentitäten erhalten beim Zugriff auf unterschiedliche URLs unterschiedliche Namensräume. Beispielsweise greifen sowohl Besucher als auch Administratoren auf die Seite zu, auf die polls:index verweist, erhalten jedoch aufgrund unterschiedlicher Namensräume völlig unterschiedliche Ergebnisse.
Das obige ist der detaillierte Inhalt vonWas ist die Django-Entwicklungsmethode?. Für weitere Informationen folgen Sie bitte anderen verwandten Artikeln auf der PHP chinesischen Website!
