Es ist ungefähr drei Jahre her, seit ich angefangen habe, das Webframework zu verwenden. Die erste Entwicklung von Webanwendungen war PHP und Perl & CGI, aber ich habe Django vor ungefähr 3 Jahren kennengelernt und benutze es seitdem als Hauptwaffe.
Als ich anfing, es zu benutzen, war mein Titel ein Student, also begann ich ohne Erfahrung als Webingenieur. Zu dieser Zeit hatte ich keine praktischen Erfahrungen mit Webtechnologie und -design, daher versuchte ich, den Zustand des Django-Projekts zu verbessern, ohne eine konkrete Lösung zu haben. Infolgedessen konnte ich als Mitglied der Gesellschaft nützliche Erkenntnisse gewinnen.
In diesem Artikel fasse ich die Design-Erkenntnisse zusammen, die ich aus meinen Erfahrungen mit Django gewonnen habe. Persönlich habe ich ein Problem bei der Kennzeichnung des Designkonzepts, daher möchte ich es auch verbessern. Ich hoffe, ich kann Ihnen sagen, dass Sie einige gute Dinge tun können, um Ihr Django-Projekt zu verbessern.
Das Modell hier ist eine Vererbung von django.db.models.Model und ist eine Klasse, die in models.py in jeder Anwendung definiert ist.
Beispielsweise kann ein Modell, das einen Song darstellt, wie folgt geschrieben werden.
class Artist(models.Model):
name = models.CharField(null=False, max_lenght=200)
class Music(models.Model):
name = models.CharField(null=False, max_lenght=200)
artists = models.ManyToManyField(Artist)
Die Klasse "Musik", die ein Lied darstellt, hat ein Feld namens "Künstler". Dies repräsentiert den Künstler, der das Lied gemacht hat. Zum Beispiel bezieht sich "Schließen Sie Ihre Augen" auf "Ken Hirai Modell".
In diesem Fall ist die Rolle von "Ken Hirai" in dem Song jedoch nicht angegeben. Viele Menschen haben das vorausgesetzte Wissen, dass "Ken Hirai = Sänger", aber Maschinen können keine Informationen haben, es sei denn, die Voraussetzungen, die Menschen haben, sind klar angegeben.
Es ist auch möglich, die Fähigkeiten des Künstlers dem "Künstler" -Modell zu vermitteln. Es ist jedoch häufig der Fall, dass selbst ein Künstler mehrere Waffen besitzt und nur eine von mehreren Fähigkeiten anbietet, je nachdem, wie er zusammenarbeitet. Zum Beispiel mag Genshi Yonezu das Bild eines "Sängers" im Allgemeinen haben, aber er liefert auch Musik. Was ist, wenn der Künstler, der das Lied erhalten hat, "feat. Genshi Yonezu" ist? Der Künstler, der das Lied erhalten hat, spiegelt nicht die Gesangsfähigkeit von Genji Yonezu in seiner Arbeit wider.
In solchen Fällen denke ich, dass die Assoziation zwischen dem Lied und dem Künstler einige zusätzliche Informationen enthält. In diesem Fall ist die Art und Weise, wie die Modellklasse geschrieben wird, meiner Meinung nach wie folgt.
class Artist(models.Model):
name = models.CharField(null=False, max_lenght=200)
class Music(models.Model):
name = models.CharField(null=False, max_lenght=200)
class MusicArtist(models.Model):
music = models.ForeignKey(Music, on_delete=models.CASCADE)
artsit = models.ForeignKey(Artist, on_delete=models.CASCADE)
as_vocalist = models.BooleanField(default=False)
as_producer = models.BooleanField(default=False)
"Künstler" aus der "Musik" -Klasse entfernt und ein neues "MusicArtist" -Modell definiert. Das Modell "MusicArtist" verweist extern auf die Modelle "Music" und "Artist". Es enthält auch die Felder "as_vocalist" und "as_producer" als Status.
Durch Definieren des "MusicArtist" -Modells wie oben beschrieben ist es möglich, zusätzliche Informationen in der Assoziation zwischen Musik und Kunst aufzuzeichnen. Selbst wenn das Lied, an dem Genshi Yonezu als Musikanbieter teilgenommen hat, den Titel "feat. Genshi Yonezu" trägt, wird klargestellt, dass er als Produzent und nicht als Sänger teilnimmt.
Zusätzlich zu der Tatsache, dass das "Artist" -Modell und das "Music" -Modell unabhängig voneinander definiert wurden, wurde ein neues "MusicArtist" -Modell unabhängig voneinander definiert. Die Künstlerinformationen des Songs sollten im Feld "Music.artists" gespeichert werden, aber sie werden nun unabhängig als Assoziationsinformationen mit einem neuen Status existieren.
Darüber hinaus kann gesagt werden, dass die folgenden Anstrengungen durch die obigen Bemühungen unternommen wurden.
Die Normalisierung von Tabellen ist eine wesentliche Aufgabe bei der Entwicklung von Back-End-Webanwendungen.
In Django repräsentiert ein Modell grundsätzlich eine Tabelle. Wenn in einem Modell ein extern referenziertes Feld vorhanden ist, erstellen Sie drei Tabellen, einschließlich einer Zwischentabelle, die die beiden Modelle verbindet.
Im Allgemeinen halte ich es für gut, wenn die Normalisierung der Tabelle bis zur dritten Normalform abgeschlossen ist. In meinem Fall scheint es jedoch so zu sein, dass die oben erwähnte Aufteilung der Modellklassen bis zum Punkt 5. Normalform implementiert wurde. Die Modellklassen wurden aufgeteilt, um sie in Bezug auf Design und Zweck schön aussehen zu lassen, aber sie haben unrealistische Artefakte für den Produktionsgebrauch erzeugt.
Sie können eine Tabellennormalisierung erreichen, indem Sie die Modellklasse unterteilen. Eine Übernormalisierung kann jedoch die Ausführung von Abfragen erheblich verlangsamen. Mit Django ist es möglich, die Modellklasse so zu betreiben, dass sie nicht wächst, während Sie darauf achten, sie nicht zu übertreiben und die Indizierung effektiv zu nutzen.
Ich verstehe domänengetriebenes Design nicht, wie Sie aus Erics Buch und seinem ersten Karrierejahr ersehen können. Durch das Streben nach einem hoch entwickelten Django-Modell habe ich jedoch das Gefühl, die Essenz von DDD berühren zu können.
Im obigen Beispiel haben wir beispielsweise ein Modell namens "MusicArtist" zu einem Modell namens "Music" hinzugefügt, das ein Lied darstellt, und ein Modell namens "Artist", das einen Künstler darstellt. MusicArtist ist das Konzept des Künstlers, der die Musik geschaffen hat, aber es ist jetzt möglich, die Informationen über die Rolle des Künstlers, der an der Musikproduktion beteiligt ist, aus den Informationen auszudrücken, an denen er gerade teilnimmt. Es war. Mit anderen Worten, bei der Verfeinerung der Modellklasse von Django wurde die Domäne destilliert und in der Modellklasse dargestellt.
Persönlich bin ich der Meinung, dass die domänengetriebene designähnliche Erfahrung, die durch die Verfeinerung der Modellklasse gewonnen wurde, eine sehr starke Erfahrung ist. Im Falle eines Produktionsbetriebs gibt es meines Erachtens eine Grenze, um die Domäne auch in Django nur mit der Modellklasse auszudrücken, aber indem die Modellklasse im Detail zerlegt und definiert wird, ohne die Produktion anzunehmen, die 5. Normalform Zusätzlich zu dieser Erfahrung konnte ich gleichzeitig die Klassendarstellung der Domäne erleben.
Es gibt ein eloquentes Modell in Laravel, aber ich denke, dass das eloquente Modell wie die Django-Modellklasse eine Grenze beim Ausdrücken der Domäne hat. Mit anderen Worten, es ist notwendig, eine neue Klasse zu definieren, die die Domäne ausdrückt, aber ich denke, dass die Erfahrung der Verfeinerung der Modellklasse von Django hier genutzt werden kann.
Als ich anfing, Django zu verwenden, gab es keinen Grund oder Zweck für die Auswahl. Infolgedessen konnte ich viel Wissen und Ideen erwerben, indem ich versuchte, die Konfiguration und das Design mit Django zu bereinigen. Ich habe es wegen des Skalierungsproblems weggelassen, aber die Existenz des Django REST Framework gab mir natürlich eine Idee wie eine ressourcendenkende Architektur. Ich kann Django nur Studenten empfehlen, die darüber nachdenken, mit dem Webframework zu beginnen! !!
Ich bin noch in meinem ersten Jahr als Softwareentwickler, daher denke ich, dass es möglicherweise falsche Beschreibungen und Anerkennungen enthält, aber ich würde es begrüßen, wenn Sie darauf hinweisen könnten.
(Die Veröffentlichung hat sich aufgrund des vollständigen Adventskalenders verzögert. Es tut mir leid!)
Recommended Posts