où exactement la logique métier python doit-elle être placée dans django


26

Je viens de commencer à apprendre le développement Django / Python / Web. Ce problème me préoccupe depuis un certain temps maintenant.

Je crée une application avec plusieurs modèles dans Django. J'ai un views.py qui ne fait que rendre les réponses aux modèles respectifs et j'ai un models.py où j'ai structuré ma base de données. Dans l'un de mes modèles, j'ai besoin de télécharger une image (ce que je suis capable de faire) et j'ai besoin d'exécuter une logique qui est basée sur les fonctionnalités de l'image téléchargée (pas encore fait). Cette logique implique beaucoup de calculs lourds. Après avoir effectué les calculs, la logique doit renvoyer certaines informations traitées (coordonnées) au modèle.

J'ai pu effectuer toutes ces actions avec succès dans une application de bureau python autonome appelant des fichiers python les uns après les autres. Cependant, puisque je veux maintenant en faire une application web, j'ai commencé à utiliser le framework Django.

J'ai fait beaucoup de recherches mais je ne suis toujours pas en mesure de savoir où placer exactement ce fichier Python contenant toute la logique. Dois-je avoir un autre fichier basé sur une classe (logic.py)et l'appeler depuis le view.py? J'ai recherché sur Google et constaté que de nombreux développeurs placent leur logique métier dans leur models.py dans Django. Cependant, je pense que ce n'est intuitivement pas correct puisque le modèle devrait communiquer exclusivement avec le back-end. Toute aide serait appréciée.Merci à l'avance.



J'ai trouvé un article qui traite de ce sujet de manière approfondie (avec la pyramide à l'esprit, pas Django). A quelques rires sensibles: nando.oui.com.br/2014/04/01/…
kratenko

Réponses:


16

J'ai fait beaucoup de recherches mais je ne suis toujours pas en mesure de savoir où placer exactement ce fichier Python contenant toute la logique.

Il existe un certain nombre d'options, selon vos besoins:

  1. Ajoutez la logique, par exemple au Imagemodèle. C'est une option utile si vous devez stocker des métadonnées par image dans la base de données et que chaque instance de modèle (chaque image) est traitée par elle-même.

  2. Ajoutez la logique en tant que Imageclasse Python ordinaire , par exemple dans un fichier appelé image.py. Rien dans Django ne vous empêche d'ajouter de la logique autre que celle des modules viewsou models. C'est une bonne option si la logique d'image est un composant central de votre application Django (par exemple une application de traitement d'image).

  3. Créez un projet Python distinct qui fournit la logique, puis appelez-le à partir de vos vues. Assurez-vous d'installer ce projet dans l'environnement Python de votre application Django. Cette option est valide si le but de votre application Django est de télécharger et d'afficher des images, ou d'afficher les résultats du traitement d'image en réponse directe à la demande d'un utilisateur, mais où le traitement d'image pourrait également être utilisé par d'autres projets.

  4. Créez une application distincte qui traite les demandes de manière asynchrone et est exécutée séparément de votre application Django. Cette option est utile si vous devez découpler le traitement d'image du cycle de demande de l'application, traiter un grand nombre d'images ou lorsque chaque calcul prend trop de temps à résoudre dans le temps d'un cycle de demande (disons dans un délai maximum de 500 ms à 1 s) .

Je pense que ce n'est intuitivement pas correct car le modèle devrait communiquer exclusivement avec le back-end.

Il n'y a rien dans Django qui nécessite un modèle pour communiquer avec le back-end, ou plutôt la base de données. Je pense que vous mélangez la sémantique de ce que Django considère généralement comme un modèle (à savoir, une abstraction d'une ou plusieurs tables dans la base de données), par rapport au terme modèle en tant que construction de conception (par exemple, comme dans la conception pilotée par le domaine).


Merci! C'était vraiment perspicace. Je pense que l'option numéro 3 devrait être assez bonne pour moi. :)
adrita

Il est normal de noter la réponse négative, mais veuillez ajouter un commentaire afin que je puisse l'améliorer
miraculixx

5

Daniel Greenfeld, co-auteur de "Two Scoops of Django, recommande que la logique métier soit dans les modèles" lorsque cela est possible, ou dans les formulaires si vous le devez. "Quant au possible double de Bart, django peut être similaire à MVC mais il est pas MVC. Comme expliqué ici dans la FAQ officielle de la documentation de Django . @adrita, je pense que vous devrez peut-être consulter la documentation officielle pour vous aider à mieux comprendre le concept des modèles, des vues et des modèles.


merci pour vos suggestions. passera sûrement par la documentation :)
adrita

Heureux que vous l'ayez corrigé, @miraculixx a donné une explication solide. Si vous êtes sur fb, rejoignez le groupe de framework python django.
diek

2

Dans les documents officiels de Django https://docs.djangoproject.com/en/1.11/ , il est dit:

Django a le concept de «vues» pour encapsuler la logique responsable du traitement de la demande d'un utilisateur et du retour de la réponse. Trouvez tout ce que vous devez savoir sur les vues via les liens ci-dessous:

Django recommande que la logique soit contenue dans les vues.


3
Ce n'est pas nécessairement la même chose que la logique métier.
FirstLastname

1
Je ne suis pas d'accord avec cette interprétation de la documentation Django. Ailleurs dans la documentation Django (par exemple pour Model.clean()), il est implicite un peu plus explicitement que (si nous nous contentons d'un projet Django réel avec des modèles, des modèles et des vues) - la logique métier (ou à tout le moins, la validation) appartient au couche modèle. Notez que je n'ai pas inclus de formulaires dans cette simplification, qui sont également acceptables.
Kye R
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.