Cela fait environ trois ans que j'ai commencé à utiliser le framework Web. Le premier développement d'applications Web a été PHP et Perl & CGI, mais j'ai rencontré Django il y a environ 3 ans et je l'utilise comme arme principale depuis.
Quand j'ai commencé à l'utiliser, mon titre était étudiant, j'ai donc commencé sans aucune expérience en tant qu'ingénieur web. A cette époque, je n'avais aucune expérience pratique en technologie et design web, donc j'essayais d'améliorer l'état du projet Django sans avoir de solution concrète. En conséquence, j'ai pu obtenir des informations utiles maintenant que je suis membre de la société.
Dans cet article, je vais résumer les idées de conception que j'ai tirées de mon expérience avec Django. Personnellement, j'ai un problème dans l'étiquetage du concept de design, donc je vise également à l'améliorer. J'espère pouvoir vous dire qu'il y a de bonnes choses que vous pouvez faire pour améliorer votre projet Django.
Le modèle ici est un héritage de django.db.models.Model et est une classe définie dans models.py dans chaque application.
Par exemple, un modèle qui représente une chanson peut être écrit comme suit.
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)
La classe Music qui représente une chanson a un champ appelé ʻartists`. Cela représente l'artiste qui a fait la chanson. Par exemple, «Fermez les yeux» fait référence au «modèle Ken Hirai».
Cependant, dans ce cas, le rôle de "Ken Hirai" dans la chanson n'est pas précisé. De nombreux humains ont la connaissance préalable que "Ken Hirai = chanteur", mais les machines ne peuvent avoir d'informations que si les conditions préalables que les humains ont sont clairement énoncées.
Il est également possible de donner les compétences de l'artiste au modèle «Artiste». Cependant, il arrive souvent que même un artiste soit multi-armes et n'offre qu'une seule des multiples compétences en fonction de la façon dont il collabore. Par exemple, Genshi Yonezu peut avoir l'image d'un «chanteur» en général, mais il fournit également de la musique. Et si l'artiste qui avait reçu la chanson était "feat. Genshi Yonezu"? L'artiste qui a reçu la chanson ne reflète pas la capacité de chant de Genji Yonezu dans son travail.
Dans de tels cas, je pense qu'il peut y avoir des informations supplémentaires dans l'association entre la chanson et l'artiste. Dans ce cas, je pense que la façon d'écrire la classe modèle est la suivante.
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)
Suppression des «artistes» de la classe «Music» et définition d'un nouveau modèle «MusicArtist». Le modèle MusicArtist fait référence extérieurement aux modèles Music et ʻArtist. Il contient également les champs ʻas_vocalist et ʻas_producer` comme états.
En définissant le modèle MusicArtist comme décrit ci-dessus, il est possible d'enregistrer des informations supplémentaires dans l'association entre musique et art. Avec cela, même si la chanson à laquelle Genshi Yonezu a participé en tant que fournisseur de musique s'appelle "feat. Genshi Yonezu", il est clairement indiqué qu'il participe en tant que producteur, pas en tant que chanteur.
En plus du fait que les modèles «Artiste» et «Musique» ont été définis indépendamment jusqu'à présent, le nouveau modèle «MusicArtist» a été défini indépendamment. Les informations sur l'artiste de la chanson étaient censées être conservées dans le champ Music.artists, mais elles existeront désormais indépendamment en tant qu'informations d'association avec un nouvel état.
De plus, on peut dire que les efforts suivants ont été faits grâce aux efforts ci-dessus.
-Nième forme normale
La normalisation des tables est une tâche essentielle dans le développement d'applications Web back-end.
Dans Django, un modèle représente essentiellement une table. En outre, s'il existe un champ référencé en externe dans un modèle, créez trois tables, y compris une table intermédiaire qui relie les deux modèles.
En général, je pense qu'il est bon que la normalisation du tableau soit complétée jusqu'à la troisième forme normale. Cependant, dans mon cas, du fait que la division de classe de modèle mentionnée ci-dessus est devenue amusante, il semble qu'elle ait été implémentée jusqu'au point appelé 5ème forme normale. Les classes de modèles ont été divisées pour les rendre belles en termes de conception et d'utilisation, mais elles ont produit des artefacts irréalistes pour une utilisation en production.
Vous pouvez réaliser une normalisation de table en subdivisant la classe de modèle. Cependant, la normalisation excessive peut ralentir considérablement l'exécution des requêtes. Avec Django, il est possible de faire fonctionner la classe de modèle pour qu'elle ne grandisse pas, en faisant attention à ne pas en faire trop et en utilisant efficacement l'indexation.
Je ne comprends pas la conception axée sur le domaine, comme vous pouvez le voir en lisant le livre d'Eric et au cours de sa première année de carrière. Cependant, en recherchant un modèle Django sophistiqué, je sens que j'ai pu toucher l'essence de DDD.
Par exemple, dans l'exemple ci-dessus, nous avons ajouté un modèle appelé MusicArtist à un modèle appelé Music qui représente une chanson et un modèle appelé ʻArtist` qui représente un artiste. «MusicArtist» est le concept de l'artiste qui a créé la chanson, mais il est maintenant possible d'exprimer les informations sur le rôle de l'artiste impliqué dans la production de la chanson à partir des informations selon lesquelles il ne fait que participer. C'était. En d'autres termes, lors du processus de raffinage de la classe modèle de Django, le domaine a été distillé et représenté dans la classe modèle.
Personnellement, je pense que l'expérience de conception axée sur le domaine acquise en affinant la classe de modèle est une expérience très puissante. Dans le cas de l'opération de production, je pense qu'il y a une limite à exprimer le domaine uniquement avec la classe modèle même dans Django, mais en décomposant et définissant la classe modèle en détail sans assumer la production, la 5ème forme normale En plus de l'expérience, j'ai pu expérimenter la représentation de classe du domaine en même temps.
Il y a un modèle éloquent dans Laravel, mais je pense que le modèle éloquent, comme la classe de modèle Django, a une limite dans l'expression du domaine. En d'autres termes, il est nécessaire de définir une nouvelle classe qui exprime le domaine, mais je pense que l'expérience de raffinage de la classe de modèle de Django peut être utilisée ici.
Quand j'ai commencé à utiliser Django pour la première fois, il n'y avait aucune raison ni aucun but de sélection. En conséquence, j'ai pu acquérir beaucoup de connaissances et d'idées en essayant de nettoyer la configuration et la conception à l'aide de Django. Je l'ai omis à cause du problème d'échelle, mais l'existence du Django REST Framework m'a naturellement donné une idée comme une architecture de réflexion sur les ressources. Je recommande vivement Django aux étudiants qui envisagent de se lancer dans le framework web! !!
Je suis encore dans ma première année en tant qu'ingénieur logiciel, donc je pense qu'il peut contenir des descriptions et une reconnaissance incorrectes, mais j'apprécierais que vous puissiez le signaler.
(La sortie a été retardée en raison du calendrier de l'avent complet. Je suis désolé!)
Recommended Posts