Résolue

Django, modèle Order ou non pour un projet type e commerce

# Notions théoriques # Bases de données

Gabriel Trouvé

Mentor

Bonjour,
Je me demandais. Pour un projet style e commerce. J'ai toujours l'habitude de passer par un modèle Order entre le produit et le panier.
Je me suis demandé s'il on pouvait mettre direct l'article dans le panier sans passer par Order. Sachant que dans le projet market place il n'y a pas de champ quantity car les annonces sont uniques.

Mais je trouve ça moyen. Ne serait ce que pour les formsets, ça ferait manipuler l'objet lui même. Et donc potentiellement supprimer l'instance du produit. Si dans mon panier je décide de faire un formset.

Donc au final je me suis retrouvé a faire un Order pour le market place. Bien que je voulais mettre direct les articles dans le panier .

merci ^^

Salut Gab,
Je me souviens que je m'étais posé la question quand j'avais fait la formation DocShop ! Je pense que tu t'es auto répondu, c'est bien plus pratique de manipuler des orders avec la date d'achat, l'expiration etc que le produit en lui même. Même si la quantité est unique, comment tu supprimerais ton article sans supprimer le produit associé pour vider le panier par exemple ? Je pense que l'intermédiaire Order qui fait le lien entre le Product et le Cart est bien plus pratique à gérer!
Bon courage pour ton projet!
Hugo

Gabriel Trouvé

Mentor

Salut Hugo, effectivement je me suis fait la même réfléxion ^^. Sur un projet j'avais carrément mis une date d'achat directement sur l'objet en vente car il n'y avait pas de quantité non plus.

Mais vraiment je trouve que le modèle intermédiaire est plus permissif.

J'en reviens aux formsets. C'est bien plus simple de les faire sur un modèle Order, et tu peux delete tes instances à la voler.

Je suis curieux de voir s'il y a d'autre avis aussi^^

J'ai vu sur le discord que Thibault a prévu de répondre aussi ^^

Thibault houdon

Mentor

C'est exactement ce que Hugo a décrit, ça te fait un modèle intermédiaire qui permet de stocker plein d'informations. Sur le projet e-commerce je l'avais fait notamment parce que généralement quand tu passes une commande sur un site, tu veux avoir un historique des commandes passées.

Si tu n'as pas ce modèle intermédiaire Order, c'est compliqué. Tu peux effectivement aller jusqu'au processus d'achat en indiquant que des articles sont dans le panier de tel ou tel utilisateur. Mais une fois la commande passée, tu n'as pas vraiment d'endroits pour stocker l'heure de la commande, le montant total, les articles achetés, etc. Toutes sortes d'informations qui sont indispensables à avoir pour un client.

Gabriel Trouvé

Mentor

100% ok j'utilise toujours un model Order sauf ci-dessous sur ma première app après le Docshop ^^

Sur ancienne appli j'ai réussi à tout gérer de A à Z avec un modèle de "produit" et un "panier par exemple.

Mais c'est un cas précis où tu n'as pas de quantité.

Donc je pense que selon les cas il y a moyen de se passer d'un modèle Order.

Du coup on peut clôturer si c'est ok. J'allais parler d'un concept que j'ai intégré dans mon app de jeu de rôle qui pourrait pourrait faire écho à tout ça mais ça serait preque hors sujet lol.

class Idea(models.Model):
    name = models.CharField(max_length=200, verbose_name="Nom", unique=True)
    slug = models.SlugField(blank=True, unique=True)
    summary = models.CharField(max_length=1000, verbose_name="Résumé")
    level = models.CharField(choices=[(str(i), str(i)) for i in range(1, 4)],
                             help_text="1 : rapide, 2 : moyennement développé, 3 : très développé",
                             max_length=1,
                             verbose_name="Niveau",)
    category = models.ForeignKey(Category, on_delete=models.SET_NULL, verbose_name="Catégorie", null=True)
    thinker = models.ForeignKey(AUTH_USER_MODEL, on_delete=models.CASCADE,
                                verbose_name="Utilisateur", related_name="ideas")
    details = RichTextField()
    sketch = models.ImageField(upload_to="sketch_idea", blank=True, null=True, verbose_name="Croquis")
    date = models.DateField(auto_now_add=True)
    request = models.BooleanField(default=False, verbose_name="Demande d'idée",
                                  help_text="Cocher si c'est une demande d'idée,"
                                            " si c'est une idée (offre) ne pas cocher")
    status = models.BooleanField(default=False, verbose_name="Publié")
    price = models.FloatField(default=0, verbose_name="Prix")
    paid = models.BooleanField(default=False, verbose_name="Payé")
    buyer = models.ForeignKey(AUTH_USER_MODEL, on_delete=models.CASCADE,
                              verbose_name="Acheteur", null=True, related_name="purchases", blank=True)
    ordered_date = models.DateField(verbose_name="Date d'achat", null=True, blank=True)

Chaque cas de figure est différent, tu peux aussi effectivement mettre plus de champs sur un seul modèle, le problème de cette approche souvent c'est que c'est plus difficile à maintenir et que tu peux te retrouver avec un seul modèle qui gère tout et qui contient 20 champs ou plus.

C'est un peu comme en programmation en général en fait, il faut séparer les responsabilités au maximum.

Ça permet si tu dois faire un changement de le faire à une petite échelle sans avoir besoin de changer une fonction, un modèle, une classe, un fichier, ou quoi que ce soit, qui est devenu immense.

Gabriel Trouvé

Mentor

C'est un peu comme en programmation en général en fait, il faut séparer les responsabilités au maximum.

Merci Thibault. Et oui j'avoue que sur netRPG je sépare pas mal les choses. Je me suis même créé un package models avec différents .py.

En tous cas merci, c'est une question que je trouvais un peu inutile à la base mais en fait ça a son importance ^^

Inscris-toi

(c'est gratuit !)

Inscris-toi

Tu dois créer un compte pour participer aux discussions.

Créer un compte

Rechercher sur le site

Formulaire de contact

Inscris-toi à Docstring

Pour commencer ton apprentissage.

Tu as déjà un compte ? Connecte-toi.