Bonjour à tous,
Je suis en train de refondre la programmation d'une application web de type CMS et j'aurais voulu avoir vos avis sur le meilleur usage de PDO.

Pour piloter le fonctionnement de l'application, j'ai créé diverses classes avec diverses méthodes (exemple classe User, classe Ressource...).
Chacune de ces classes fait des requêtes SQL pour insérer ou lire des données dans une base. En l'état actuel, l'application est développée pour être compatible avec PHP4. J'avais donc créé une classe (pseudo couche d'abstraction) "MySQL" pour la communication avec la base de donnée et toutes mes classes créaient un objet "MySQL" pour accomplir leurs tâches.

Il est question de passer en le tout en PHP5 et d'utiliser PDO. Je me pose alors la question suivante :

- Est-ce qu'il est préférable de faire dépendre toutes mes classes de la classe PDO, en en faisant des classes filles, bénéficiant directement de toutes les méthodes de PDO ou vaut-il mieux que ces classes instancient un objet de type PDO indépendament.

Merci d'avance pour vos réponses.

Salut,

Dans le cas d'une migration vers PHP 5, si tu utilises au minimum PHP 5.2.3, je te conseille vivement de jeter un oeil à Doctrine. Il s'agit d'un ORM vraiment complet, simple à installer (simplement copier la bibliothèque sur ton serveur), et qui utilise PDO pour sa connection au SGDB.

Je l'utilise actuellement dans un développement, et je suis emballé.

De plus, dans le cas d'une application déjà existante (ce qui est ton cas), Doctrine peut t'aider à faire la migration en créant lui-même les classes correspondantes aux tables de ta base de données.

Cordialement

Bonjour VOr_X,
Merci de ta réponse, le temps de parcourir la doc de doctrine et c'est bigrement intéressant, je vais me pencher sur ce genre de possibilité car je me posais aussi la question de l'usage d'un framework pour toutes les bonnes raisons que cela comporte, comme Jelix ou PEAR.

Donc c'est la pleine effervescence, c'est toujours délicat de faire des choix comme ceux-là pour les temps de développement (entre la découverte de nouvelles pratiques/outils, la mise en application et le temps gagné finalement au bout du compte).

Toujours est-il que je constate que faire dériver des classes depuis PDO est une option que je garde sous le coude, j'aurais surtout voulu savoir si c'était déconseillé et si oui pour quelles raisons.

Salut,

Faire dériver directement tes classes de PDO n'a, je pense, pas d'intérêt (tu te prives d'avoir ta propre arborescence de classes, et en plus, cela veut dire que tu devras "connecter" chacune de tes classes au SGBD). De toute, façon, si tu utilises Doctrine, tu n'auras pas à te poser la question (toutes les classes qui mappent une table de ta BD héritent de Doctrine_Record).

Si tu es à la recherche d'un framework, je te conseille un "super combo" :

• Zend Framework
• Doctrine
• Smarty (qui peut être utilisé comme vue avec ZF en créant une classe implémentant Zend_View_Interface)

Avec tout ça, tu as une bonne base.

Cordialement

Hello,

hériter de PDO est plutôt lourd et chiant au final, et certainement contre-performant : ouvrir une connexion à la base de données pour chacun des objets que tu vas instancier, ce n'est pas génial comme approche.
Pour de petits sites/projets, une simple fonction/méthode retournant un singleton de la connexion devrait suffire.

Après pour ce qui est du mapping type Doctrine, c'est histoire de goût. Je préfère pour ma part conserver la maîtrise du SQL utilisé.

Sinon pour le choix du "Framework", il me semble que Jelix intègre une couche d'abstraction à la base de données, ainsi qu'un moteur de template ; ce qui peut éviter d'avoir à jongler entre les docs de Zend Framework, Doctrine et Smarty.

Je prêche pour ma paroisse, mais si vous voulez utiliser un framework :
- CakePHP
- Symfony
- Jelix
- CodeIgniter
Je n'ai pas suffisamment testé Zend Framework pour donner un avis, mais j'ai toujours le sentiment d'une super bibliothèque de classes plutôt que d'un framework.

Bonsoir,

Quelques précisions sur le fonctionnement de mes scripts, j'utilise SMARTY comme moteur de templates.
Classiquement, dans mes scripts "contrôleurs", je crée donc mes objets (que j'appelle "de gestion" pour me faire comprendre) qui vont eux dialoguer avec la base de données (insertion, rapatriement...) et éventuellement formater les données. Le contrôleur s'occupe ensuite de les injecter dans le moteur de templates. Je n'utilise pas les connexions persistantes.

Pour dialoguer avec la base de données, les objets de gestion en question instancient eux-mêmes un objet à leur création qui établit la connexion avec la base, et utilisent ses méthodes pour exécuter les requêtes, gérer les erreurs etc. Lorsque plusieurs de ces objets de gestion sont crées, ils utilisent la connexion ouverte par le premier objet de gestion créé dans le contrôleur (et c'est le dernier qui en a l'usage qui clôt la connexion). Cela est possible parce que j'utilise les mêmes identifiants de connexion et que je laisse PHP me renvoyer le lien de la connexion déjà ouverte, mais bon je ne n'apprend rien à personne je pense.

Ensuite je ne sais pas trop ce vaut ma méthode...



Voilà justement une question que je me suis posée. PDO ouvre une nouvelle connexion à chaque instanciation d'objet ou se comporte-il comme décrit ci dessus, utilisant la connexion ouverte? (Plutôt que de poser la question je vais aller tester ça , mais ça me semblerai idiot qu'il établisse une nouvelle connexion s'il y en a déjà une d'ouverte).

Pour revenir sur les frameworks, merci de vos contributions, j'imagine qu'il y a déjà quantité de discussion à leur sujet et ce n'était pas le but initial de ce thread mais ça m'aura fait mettre la main sur des trucs intéressants.

pourquoi ne pas appliquer un motif Singleton sur ton objet qui utilise PDO.
Si l'objet existe déjà, alors on le réutilise.

Je suis passé par une étape similaire :
adodb, dispatcher / controleur "maison", smarty.

Au final, j'utilise CakePHP

Merci à tous pour votre participation,
je vais utiliser un motif Singleton pour récupérer l'objet PDO, je ne connaissais pas cette technique là, j'ai bien fait de passer par là !