Repository dans entite

Bonjour

J'ai une commande qui contient des ligne de commande (donc commande et commande_ligne) j'aimerais avoir une methode dans l'entite commande getPrix(). Mais je ne sait pas comment faire vue que je n'est pas accés au Repository dans l'entite. A l'epoque avec Symfony 1 j'aurais fait:

Code:

---

1 2 3

public function getPrix(){ return Doctrine::getTable('Commande_ligne')->getSumPrixByCommande($this->getId()); }

---

Avec la requete DQL dans CommandeLigneTable.

Alors dans le cas de SF2 j'aimerais vraiment comprendre comment faire et qu'elle est la bonne méthode.

Bien sûre je ne veux pas ajouter une colonne prix dans commande histoire de respecter Merise et je ne veux pas boucler sur toutes mes ligne_commandes pour retrouver Sum(prix).

De plus j'aimerais savoir comment ordonner mes commandeligne dans ma variable Commande:$commandelignes.

Merci pour votre aide.

Bonjour,

en toute logique tu as une liaison 0-n entre ta commande et les lignes de ta commande.

Citation:

---

et je ne veux pas boucler sur toutes mes ligne_commandes pour retrouver Sum(prix)

---

Pourquoi ?

C'est exactement ce qu'il faut faire. Une fois ta commande chargée tu peux boucler sur tes lignes de commandes. Du coup dans ton entités commande tu créer une fonction

Code:

---

1 2 3 4 5 6 7 8 9 10 11

public function getTotal(){   $total = 0;   foreach($this->orderLines as $line){ $total = $total + ( $line->getQuantity() * $line->getPrice() ) }   return $total;   }

---

Hello : en effet une boucle est la solution la plus appropriée (simple correction d'un oubli : il s'agirait de $this->orderLines dans son morceau de code).

Jamais tu n'auras de repository dans une entité Symfony2 : c'est vraiment très vilain de vouloir faire ça.
D'autant plus que tu n'as pas besoin de faire appel au repository : tu ferais une requête supplémentaire inutile car tu possède déjà toutes les infos.

Il faut simplement t'assurer au moment ou tu récupère ton objet 'commande' que tu as également récupéré la collection d'articles (ou de lignes de commande) qui va avec pour que Doctrine n'ait pas à faire une requête de lazy-loading à chaque passage dans ta boucle.

méthode 1: utiliser les relations liées pour effectuer le calcul

Code:

---

1 2 3 4 5 6 7

public function getPrix(){ $sum = 0; foreach( $this->getCommandeLignes() as $commandeLigne) { $sum += $commandeLigne->getPrix(); } return $sum }

---

Cette méthode est facilement implémentable, mais elle est dangeureuse car elle te force a faire des jointures dans chacunes de tes requetes, le moindre oubli peut entrainer un nombre de requete assez grand.

méthode 2:
Il faut créer un objet métier commande, qui n'est pas un objet doctrine, mais qui est instancié a partir de différents repository etc... via un service par exemple.
Après t'as ton entité qui est manipulable super facilement
Ducoup instancier cette classe en faisant appel a un service.

Mais un SUM() en SQL n'est il pas plus rapide qu'un foreach += en php sur tous dans le cas ou le nombre de ligne atteins des sommet ?
J'aimerais comprendre d'un coter accéder au repo c'est pas le travail de l’entité mais de l'autre faire un SUM c'est pas celui de PHP.
Et pour ordonner quelle est alors la meilleur solution ?

En tous cas merci pour vos réponse rapide :)

faire un sum c'est plus rapide, mais ton panier est pas toujours a 100% persisté dans la base non?

C'est un exemple en réaliter je n'ais pas de commande et pas de lignes. C'est une question que je me pose en générale. Si le sum est plus rapide le sum est donc une meilleur solution non ? Puis pour ordonner comment faire ?
Sinon de manière générale je persiste le plus possible de manière a faire baisser le nombre de requête au maximum.

Si tu souhaites faire baisser le nombre de requêtes au maximum, alors il semble logique d'éviter de faire une requête pour obtenir un résultat que tu peux obtenir sans cette requête.

Selon les cas de figure, il y a d'autres possibilités :

La mise à jour d'un champ non mappé directement depuis les setters peut être une solution. Cela permet d'accéder directement à la valeur qui a été incrémentée en live. Seul inconvénient, à moins de stocker l'objet en session, on perd les données non mappées à chaque rafraichissement de page, ce qui oblige le recalcul à l'instanciation (la boucle).

Pour des calculs plus complexes sur une durée de temps plus longue, il m'est déjà arrivé d'utiliser des vues matérialisées. Ces vues comprennent alors le(s) résultat(s) des calculs à faire.

Il y a aussi la requête qui te retourne l'objet et le SUM dans la même requête. Je n'aime pas du tout cette option car elle ne retourne pas un objet 'propre', mais un tableau avec un objet, et à coté le résultat (qui ne correspond à aucun champs happé) à part.


Bref les façons de faire ne manquent pas : à toi de voir ce sur quoi tu mets la priorité. Si tu veux économiser le nombre de requêtes, ou du temps d'exécution, si ta requête en question est exécutée très peu de fois, ou au contraire à chaque chargement de page... Mais ce n'est pas parce que le SUM est plus rapide qu'il est mieux : ça dépend uniquement de tes priorités. Si ta requête est plus rapide avec un SUM mais qu'elle explose le nombre de connexions BDD et que derrière ça ralentit tout le reste de la navigation sur les autres parties, tu n'es pas gagnant dans l'affaire.