Discussion :

[grinder59]

Bonjour,

Je suis en train de développer une application en utilisant Symfony2 (appli qui me sert à mettre en pratique mon autoformation sur ce framework). Si Symfony2 me convainc, Doctrine2 me laisse de marbre. Ayant pour habitude de tuner mes bases de données, j'ai vraiment du mal avec Doctrine2, dont je ne dis pas qu'il n'a pas de qualités, je dis juste que je n'y suis pas sensible...

Afin de respecter le modèle MVC, je souhaiterai isoler ma couche modèle afin de ne pas faire mes requêtes dans les controllers. J'ai pensé créer faire un service de connexion à la base de données et créer des classes pour faire mes requêtes (à organiser par fonctionnalités), ces classes étant chargées par autoload.

Est-ce la bonne façon de faire ? et dans ce cas, où mettre ces fichiers de classes ? Existe-t-il une autre façon de faire plus adaptée ?

Merci de vos conseils !

[Nico_F]

Hello,

Rien ne t'empêche de faire des requêtes natives là ou on retrouve habituellement le DQL, c'est à dire dans le repository dont la fonction principale est de retourner des résultats de requêtes quels que soient leurs formats de retour.
Ces requêtes te retourneront des résultats sous forme de tableaux dégueulasses que tu traiteras tel quel comme un goret ou que tu devras mapper pour coller à un graphe d'objet qui correspond à ton modèle Symfony. Parce-que l'inconvénient, c'est que si tu ne veux pas utiliser Doctrine, ça veut dire que tu te rajoutes toi même tout le travail de mapping pour tes entités.

Ce qui nous amène à la deuxième option : utiliser les classes fournies par Doctrine afin de faire le lien entre ta requête native et ton graphe d'objet où il est supposé arriver : jète un œil au ResultSetMappingBuilder qui pourrait constituer un juste milieu entre une utilisation des outils fournis par le framework et une certaine liberté coté modèle et BDD plus particulièrement.

J'ai eu l'occasion de travailler sur un projet avec des puristes de la BDD et de la requête qui trouvaient que Doctrine (et les ORM de manière générale) était le diable en personne, mais ils ont accepté que l'on fonctionne avec des requêtes natives, et le ResultSetMappingBuilder. Bien sur, pour des requêtes complexes, il devient assez pénible de configurer le ResultSetMapping à chaque requête, mais on pourrait imaginer une couche supplémentaire qui gère la configuration du ResultSetMapping de manière plus automatique en se basant sur une convention quelconque.

À toi de jouer maintenant
GL HF

[dukoid]

pour des requêtes complexes doctrine c'est le mal, tu passe du temps à essayer de coder le truc en DQL. (ça me saoule)
de plus, niveau perf.. en objet c'est plus lent .. beaucoup plus lent.....
donc doctrine pour de petite requête simple ok mais pour des retours volumineux ou des requêtes complexes , NON, NON et NON !

[Nico_F]

pour des requêtes complexes doctrine c'est le mal, tu passe du temps à essayer de coder le truc en DQL. (ça me saoule)
de plus, niveau perf.. en objet c'est plus lent .. beaucoup plus lent.....
donc doctrine pour de petite requête simple ok mais pour des retours volumineux ou des requêtes complexes , NON, NON et NON !

Entre chercher à faire sa requête en DQL, ou bien faire le mapping des données soi-même, parfois champ par champ, je ne m'avancerais pas sur ce qui est le plus chronophage.
Pour ce qui est des performances, c'est logique puisqu'il y a une étape en moins : que ta requête soit complexe ou non, il n'y a pas de mapping donc ça va forcément plus vite. Après selon ton cas, est-ce que tu préfères manipuler des objets ou des tableaux ? Dans certains cas manipuler des tableaux est largement suffisant et donc peut-être approprié, mais il me semble que Doctrine sait aussi te retourner un tableau.

Dans la plupart des cas que j'ai rencontré, je me suis aperçu que remplacer une requête DQL par une requête native est bien souvent plus pertinent lorsqu'on a besoin de réaliser des requêtes qui comportent des traitements propres au SGBD que Doctrine ne gère pas (et qui pourront de ce fait optimiser le temps de réponse de la requête), que uniquement gagner en performances de traitement. Pour une même requête qu'il est possible de faire en DQL ou en SQL, la requête finale est sensiblement la même et je ne trouve pas que ce soit là dessus qu'on gagne en performances. En revanche, oui c'est long et très couteux en mémoire de vouloir faire une requête, même la plus simple soit elle, lorsqu'on rajoute dans le select une jointure qui va nous retourner un objet possédant une collection avec 3000 entités dedans : et là on parle bien du mapping des données.

Si le temps de traitement de la requête est significativement plus bas en natif qu'en DQL ou que la requête nécessite l'utilisation de fonctions non accessibles à Doctrine, il est pertinent d'utiliser la requête native.
Mais même la requête SQL la plus complexe du monde peut retourner un résultat léger que l'on pourra mapper. Il faudra alors différencier les requêtes complexes, des requêtes retournant des résultats volumineux.

Je pense qu'il est bien plus agréable de manipuler des objets quand il est possible de le faire, même au prix d'un mapping parfois pénible. Et je pense que les cas où l'on a vraiment besoin de manipuler des collections immenses d'objets sont rares et que des solutions existent pour ce genre de cas sans pour autant faire l'impasse sur l'ORM.

[dukoid]

Si le temps de traitement de la requête est significativement plus bas en natif qu'en DQL ou que la requête nécessite l'utilisation de fonctions non accessibles à Doctrine, il est pertinent d'utiliser la requête native.

et j'ajouterai que si on doit récupérer un certain volume ...

sinon dans l'ensemble, je suis d'accord

de plus, de nos jours on cherche la performance, bien souvent on a plusieurs requêtes à effectuer. l'accumulation de gain et même de petit gain c'est toujours bon à prendre.