ABSTRACTION PDO
webdeb
Messages postés
488
Date d'inscription
samedi 5 avril 2003
Statut
Membre
Dernière intervention
31 mars 2009
-
4 janv. 2009 à 12:54
cs_hornetbzz Messages postés 59 Date d'inscription lundi 1 décembre 2008 Statut Membre Dernière intervention 3 janvier 2011 - 28 févr. 2010 à 05:14
cs_hornetbzz Messages postés 59 Date d'inscription lundi 1 décembre 2008 Statut Membre Dernière intervention 3 janvier 2011 - 28 févr. 2010 à 05:14
Cette discussion concerne un article du site. Pour la consulter dans son contexte d'origine, cliquez sur le lien ci-dessous.
https://codes-sources.commentcamarche.net/source/48879-abstraction-pdo
https://codes-sources.commentcamarche.net/source/48879-abstraction-pdo
28 févr. 2010 à 05:14
28 févr. 2010 à 04:10
Plutôt initié que débutant, en tous cas pour moi :-)
Je n'ai pas la compétence pour juger si c'est bien codé mais en ts cas, le code est clair.
Juste une question: pour quelle raison précise PHP5.3 est-il requis ?
22 mars 2009 à 19:24
La question sur __call() est intéressante.
En terme de design pattern (motif de conception), la méthode magique __call() permet d'écrire une classe proxy (ou un wrapper). Si les performances peuvent en pâtir, il faut quand même rester réaliste : c'est pas ça qui va ralentir un serveur, même mutualisé. Et puis quand on développe en OO, qu'on respecte des design patterns, etc, les performances sont toujours un peu détériorées. Par contre, on gagne en lecture de code, en maintenabilité, évolutivité, modularité, etc.
Et puis si PDO évolue et que de nouvelles méthodes sont créées, il ne sera pas nécessaire de mettre à jours la source, alors qu'avec des méthodes réécrites, si.
22 mars 2009 à 19:07
J'ai trouvé ta source très intéressante, j'ai décidé de changer la mienne en gardant certaines options mais en prenant ton système comme base de travail.
Je me posais en revanche une question, est-ce que l'utilisation de __call n'est-elle pas lourde à la longue ?
Une solution serait de re-déclarer toutes les fonctions, un peu redondants et chiant mais sûrement plus efficace, enfin je suis pas à 3 millièmes près :)
Je vais faire des tests et j'essaierai de donner un petit feedback par la suite.
17 févr. 2009 à 21:51
je viens de tester ta classe parce que j'ai décidé d'enfin passer par pdo.
Par contre en voulant faire ton exemple j'obtiens des erreurs et ça ne marche pas :
"Warning: get_class() expects parameter 1 to be object, null given in C:\wamp\www\pdo\class.pdo_manager.php on line 137
Fatal error: Call to a member function fetchAll() on a non-object in C:\wamp\www\pdo\index.php on line 18"
Je pense que ça viens de la connexion, et donc de la création de l'objet car j'arrive pas à trouvé ou la connexion ce fait dans les class.
6 févr. 2009 à 10:48
En tout cas, je me fie aux autre personnes pour dire que c'est un joli code, même si je ne suis pas capable de le juger : c'est un trop haut niveau pour moi, un jour peut-être...
Par contre, je ne me permettrai pas de le noter
5 févr. 2009 à 15:51
5 févr. 2009 à 13:24
Ce que je voulais dire c'est que quand un développeur utilise un framework, celui-ci (le développeur) va développer pour le SGBD qu'il utilise, pas pour que ce soit compatible avec tous les SGBD de la planète. Contrairement à une application web comme un blog ou un forum qui doit pouvoir être utilisée sur n'importe quel SGBD.
Le public visé n'est pas le même : l'utilisateur final va vouloir installer (et que ça marche) avec le SGBD de son choix, le développeur qui utilise un framework va optimiser pour le SGBD qu'il utilise (et s'il en utilise plusieurs, il optimise pour que ça marche partout, c'est son affaire).
5 févr. 2009 à 12:36
5 févr. 2009 à 12:34
J'avoue quand j'utilise un framework j'utilise rarement les méthodes utilitaires ^^.
Je vais tester ce soir le rowCount en php5.3 voir ce qu'il retourne. Peut être qu'ils auront uniformisé le retour.
5 févr. 2009 à 10:45
Je serai plutot d'accord avec Neige sur le fait qu'un framework ne doit pas implémenter des tâches utilitaires pour deux raisons : ceci alourdit le framework, et, en général, n'est rarement utilisé par le développeur (qui adaptera ses requêtes à son environnement). Cependant, histoire de mettre tout le monde sur un pied d'égalité, je dirai à Neige que CodeIgniter possède des requêtes "utilitaires" :p (scaffolding par exemple).
@Neige : Ton framework ne doit pas forcément n'utiliser qu'un seul sgbd, mais plusieurs. Tu devrais utiliser une factory qui puisse te retourner plusieures instances de classes sgbd, une MySQL, un PgSQL, etc. On ne sais jamais sur quoi on peux tomber avec un framework :p
@Dorian91 : Alors je te souhaite bien du courage :) J'ai hate de voir la version terminée. Pense surtout à faire des tests de performances, car c'est très important.
@Neige : Le framework MVC qui permette de générer une interface (pas nécésssairement d'admin), c'est Symfony (si j'ai bien compris ce que tu veux, mais en tout cas Symfony ne demande pas de développement à la base).
Pour ce qui est de rowCount et MySQL, je vais t'horrifier : Ca dépends des versions ! :p Mon code marchait au travail et depuis qu'on à fait la mise à jour, tous les rowCount retournent 0 (pour les SELECT), du coup je doit revoir tout mon code ... Moralité : Il ne faut pas partir dans l'idée que MySQL est le principal utilisé et que "quelques bases de données retourneront le nombre de lignes retournées par SELECT" :p
voilà je vous ai rattrapé :p
5 févr. 2009 à 09:32
Pour PDO il tend à unifier l'accès aux BDD mais il y a tellement de différence que c'est pas gagné ^^
5 févr. 2009 à 01:55
"Si la dernière requête SQL exécutée par l'objet PDOStatement associé est une requête de type SELECT, quelques bases de données retourneront le nombre de lignes retournées par cette requête. Néanmoins, ce comportement n'est pas garanti pour toutes les bases de données et ne devrait pas être exécuté pour des applications portables."
Et je pense que ça marche avec MySQL parce que je m'en suis servi dans mes tests, quand je ne faisais pas encore gaffe à cette méthode... Cependant, il est fort probable que ça ne fonctionne pas avec postgresql ou oracle... (je dis ça, mais c'est pure spéculation).
Ca ne règle pas le problème, mais MySQL étant le SGBD le plus répandu dans le monde du webdev, cela explique qu'il soit si facile de ne pas faire attention à cette subtilité...
Comme quoi si PDO tend à unifier l'accès aux BDD, c'est vraiment pas gagné...
5 févr. 2009 à 00:43
Certains projets peuvent utiliser des SGBD différents... Oui, certes, sur de très gros projets, c'est tout à fait possible. Seulement pour accéder à un SGBD ou à un autre, on ne va pas nécessairement utiliser les mêmes scripts, même si ceux-ci utilisent les mêmes outils (ie le même framework).
Tout dépend où l'on fixe la limite de ce qu'on implémente. C'est un choix de la part du développeur (du framework) de fournir des outils plus ou moins complets (avec plus ou moins d'accessoires).
J'ai vu un framework MVC en PHP qui permet, semble-t-il de générer une interface d'admin sans quasiment écrire une ligne de code (je crois que c'est Jelix, mais je ne sais plus vraiment, et j'ai la flemme de chercher). Ils ont pris le parti de fournir un outil qui permet ceci. CodeIgniter, par exemple, non. C'est un choix. Aucun des deux n'est meilleur que l'autre. Voilà pourquoi nous risquons de ne pas être d'accord sans avoir tort pour autant ;)
Donc ok pour implémenter des utilitaires, je n'y vois aucun inconvénient, à la condition qu'on ne me reproche pas de ne pas en mettre dans mes classes (mais je peux toujours changer d'avis :)
En tout cas, j'apprécie particulièrement ces échanges que nous avons là : c'est vraiment intéressant et enrichissant (en tout cas pour moi, j'espère que c'est le cas pour vous aussi, et même pour les seuls lecteurs).
Bonne fin de soirée et bonne nuit :)
5 févr. 2009 à 00:28
@Neige : Justement dans un framework il faut des outils génériques grace aux méthodes utilitaires quelques soit la base tu utilisera toujours le meme nom de méthode. De plus pour certain projet tu peux avoir à utiliser plusieurs type de base.
4 févr. 2009 à 23:34
Mes classes sont destinées à s'intégrer dans un framework. Si elles doivent permettre l'utilisation de n'importe quel SGBD grâce à PDO, elles n'ont pas vocation, dans une même application, à servir sur plusieurs SGBD différents. Contrairement à une application (forum, blog, cms) qui doit pouvoir (autant que possible) être utilisé avec soit MySQL, soit PostgreSQL ou autre (mais un seul à la fois), un framework est utilisé non pas par un utilisateur final, mais par un développeur... Et ça fait toute la différence.
Je sais pas si c'était hors sujet ou pas, bon...
Je retravaille un peu ma source, je la posterai j'espère avant vendredi (ça laisse que demain ça... ah ouais... mince alors...)
4 févr. 2009 à 22:37
Je te souhaite d'y arriver ! Mais bon courage !
4 févr. 2009 à 20:24
Pour les méthodes utilitaires je pense qu'elle sont très pratique du moins temps que les logiciels de bdd n'aurons pas une syntaxe et des fonctions sql identique (Je pense surtout a MySQL qui deroge a pas mal de règles).
De plus ce code fait partit d'un plus gros projet qui est un active record (presque fini ^^ en fait c'est un portage de l'active record ruby en php) donc je doit avoir des syntaxes identiques pour récupérer des données sur les tables etc...
Je suis en train de me documenter sur les curseurs et réfléchir a une méthode pour les implémenters.
4 févr. 2009 à 09:49
4 févr. 2009 à 01:52
Et puis je comprends pas : d'abord tu dis que rowCount() ne sert que pour les lignes affectées par DELETE, INSERT et UPDATE, puis là, tu me dis que tu t'en sers pour savoir si tu as des news à afficher... Tu les récupères pas avec une requête SELECT tes news ? Ou alors, je suis fatigué et trop vieux, et je devrais aller me coucher... ?
4 févr. 2009 à 01:23
4 févr. 2009 à 00:50
Je comprends pas l'exemple 2 qu'on trouve sur la doc de rowCount() : http://fr.php.net/manual/fr/pdostatement.rowcount.php
Pourquoi ils utilisent fetchColumn() en parlant de ligne ? Y'a un truc qui m'a échappé ?
'tain, c'est pas génial quand même d'utiliser count(*)...
En même temps, en y réfléchissant... je me demande si avoir le nombre de lignes retournées est vraiment indispensable...
Quand on utilise les curseurs de PDO, on va pouvoir ne récupérer (facilement) que les résultats que l'on veut. Par exemple les 10 premiers (et moins s'il n'y en a pas autant). Si on veut savoir combien il y en a au total, il y a des chances qu'on soit en backend, et que donc, on puisse se permettre une requête select count(*) supplémentaire.
Avec MySQL, on peut utiliser SQL_CALC_FOUND_ROWS dans la requête SELECT si on utilise LIMIT, avec un petit select FOUND_ROWS() ensuite...
Bon mais j'avais pas fait gaffe à ça... :/
Bon ok, je vais mettre ma source. Ca fera que la 2560890334ème sur un DAO, ça fait rien... ^^
Je vais quand même m'assurer qu'elle est pas bugguée, sachant que je ne peux pas tester les curseurs de PDO, n'ayant pas de serveur Oracle sous la main (peut-être que Postgre les gère, maiis je n'ai pas non plus de serveur Postgre). Pis je dois corriger cette histoire de rowCount()...
Allez, bonne nuit les enfants !
4 févr. 2009 à 00:16
Par contre, j'aimerai juste souligner un point qui peux devenir un très gros piège (j'en ai fait l'expérience :p), la méthode rowCount NE RETOURNE PAS le nombre de ligne sélectionnée ! Elle retourne le nombre de ligne affectée UNIQUEMENT par les requêtes de type INSERT, UPDATE ou DELETE !
La doc le dit clairement, mais beaucoup de gens se sont fait/se font avoir !
http://fr2.php.net/manual/fr/pdostatement.rowcount.php
Note: du coup, aucune méthode "performante" ne permet de connaitre le nombre de lignes retournée par un select. Les deux options sont un SELECT count(col) FROM table WHERE same_conditions;" ou faire un fetchAll () puis un count (pas tip top niveau mémoire !).
3 févr. 2009 à 23:27
En fait pour mes besoins à moi, j'ai implémenté cette fonctionnalité. En fait, j'ai plusieurs classes :
- DBStatement implements Countable
- DBStatementIterator extends DBStatement implements Iterator
- DBStatementCursor extends DBStatement implements Iterator, SeekableIterator
- DBStatementCursorNative extends DBStatementCursor
- DBStatementEmulation extends DBStatementCursor
DBStatement est en fait un proxy pour un objet PDOStatement (qui est passé en argument du constructeur). La méthode count() retourne simplement PDOStatement::rowCount()
DBStatementIterator fournit un itérateur très simplifié qui ne parcourt l'objet PDOStatement qu'une seule fois, du premier au dernier enregistrement (sans rewind). C'est la base de ce qu'on attend d'un itérateur : récupérer les résultats du premier au dernier.
DBStatementCursor est une classe abstraite qui définit les méthodes next() et seek()
DBStatementCursorNative utilise les curseurs PDO : c'est la classse la plus performante dans le sens où elle utilise pleinement les curseurs.
DBStatementCursorEmulation est, comme son nom l'indique, une émulation de curseur : pour cela, j'utilise fetchAll() et je parcours le tableau ensuite avec l'itérateur. C'est moins performant puisque tous les résultats sont récupérés avant d'être ensuite parcourus 1 à 1. C'est la contrepartie de l'émulation d'une fonctionnalité. Cette classe est un peu limitée puisqu'elle n'utilise pas toutes les possibilités des curseurs et ne permet que de parcourir dans un sens, dans l'autre, ou d'accéder à un offset donné.
Bien sûr, pour chaque, il reste possible de préciser le mode de récupération (FETCH_OBJ, FETCH_ASSOC, etc).
J'ai pensé publier ma classe, mais comme il y a la tienne, je ne sais pas si c'est utile... La tienne fait des choses que la mienne ne fait pas, notamment, je n'ai écrit aucune fonction utilitaire, contrairement à toi : je me suis longtemps interrogé sur la réelle utilité méthodes utilitaires (sic) dans un DAO... En fait, il est fort probable que ça soit vraiment intéressant dans certains cas (ça simplifie quand même un peu la vie du développeur, non ?). Bref, c'est pour moi un débat qu'il serait intéressant d'avoir (mais peut-être pas ici...)
3 févr. 2009 à 21:18
dossier racine
--dossier dao
----fichier "dao_factory.class.php"
----dossier "pdo"
------fichier "pdo_manager.class.php"
------fichier "pdo_mysql.class.php"
------fichier "pdo_pgsql.class.php"
J'ai oublié de modifier le fichier zip (il contient les namespaces)
La source affiché est sans namespace
3 févr. 2009 à 21:12
Merci pour les commentaires.
linkinparkem >>> Pourrais tu me donner le message d'erreur que tu obtiens
Neigedhiver >>> Ah je ne savais pas pour le support des curseurs avec pdo mysql (pas l'habitude d'utiliser ces choses ^^). Faut que je me renseigne sur le fonctionnement des curseurs en SQL et je vois pour implementer cela.
1 févr. 2009 à 12:57
J'avais pas vraiment fait de commentaire la première fois, je vais en faire un vrai cette fois-ci... En fait il s'agit plus d'une idée de fonctionnalité que d'un vrai commentaire.
PDO_MYSQL ne supportant pas les curseurs (et c'est pas prévu tout de suite : http://bugs.php.net/bug.php?id=44475 ), pourquoi ne pas implémenter cette fonctionnalité ? J'ai du le faire pour mes besoins personnels, c'est quand même plus confortable pour développer...
1 févr. 2009 à 11:02
mais au niveau du script "dao_factory.class.php" les namespaces sont reconnus mais dans les autres scripts il me retourne une errreur ds la 2éme ligne qui concerne l'utilisation des namespace si vous avez une solution à me partager je suis preneurs et si vous avez même une version sans les namespaces sa sera l'idéal et merci d'avance ! ;-)
29 janv. 2009 à 21:35
6 janv. 2009 à 10:00
/**
* Mapping des fonction PDO
*
* @access public
* @param string $sMethod
* @param array $aArguments
* @return mixed|boolean
*/
public function __call($sMethod, $aArguments)
{
if( method_exists(get_class($this->_oPdoInstance), $sMethod) )
{
return call_user_func_array(array($this->_oPdoInstance, $sMethod), $aArguments);
}
return false;
}
Me sert a mapper les méthodes PDO. Pour pouvoir faire par exemple $oPdoMysql->query()
Je fais un méthode existe pour tester si la méthode est présente dans Pdo si non je retourne false au lieu d'une erreur PHP
Le principale interet est que si je veux lancer certaine action sur des méthodes PDO je peux le faire dans la méthode __call
Un petit exemple :
je fais un $oPdoMysql->query('SELECT tata_yoyo FROM chapeau');
La méthode query va etre attrapé par __call et je souhaite logger toutes les requetes qui passent
public function __call($sMethod, $aArguments)
{
if( method_exists(get_class($this->_oPdoInstance), $sMethod) )
{
if( $sMethod == 'query' ) Logger::add($aArguments[0]);
return call_user_func_array(array($this->_oPdoInstance, $sMethod), $aArguments);
}
return false;
}
C'est un exemple vite fais hein
La méthode __call ne sert que pour PDO d'ailleur je fais un get_class($this->_oPdoInstance) qui est une instance de PDO
En gros c'est pour avoir a dispo toutes les méthodes de ma classe + celle de pdo dans une seule instance.
Bon je sais pas si c'est clair ^^ moi et les explications ca fais 2
6 janv. 2009 à 09:39
Il peux créer une interface iMachinTruc, contenant 3 fonctions (do, go et po) mais maitenant si toi tu veux créer une nouvelle fonction qo, tu peux, mais elle ne sera pas reconnue par son code ! (si j'ai bien compris).
6 janv. 2009 à 00:37
Enlève ce "if", mets une interface, ça ne sera que plus propre et avantageux pour le maintien et l'évolution de ta classe.
6 janv. 2009 à 00:34
En gros c'est ma façon de faire. Après je me trompe peut être, je ne suis pas un gourou de la poo ^^.
6 janv. 2009 à 00:18
abstract protected function _getDsn();
abstract protected function _setConnectionEncoding();
abstract public function describe($sNameTable, $sSchema = null);
abstract public function listTable();
Si tu étend la classe PdoManager sans implémenter ces méthodes tu aurras une erreur comme avec les interfaces.
5 janv. 2009 à 23:14
Oui, mais encore mieux : l'interface vérifie si toutes les méthodes obligatoires ont bien été implétmentées... Il me semble que pour une source obligeant à PHP5.3, l'orienté objet doit être encore plus "pro", et ajouter une interface à ta classe n'est qu'un travail de quelques secondes. Pourquoi s'en priver ? en plus tu encourages les autres programmeurs à étendre ta classe...
5 janv. 2009 à 14:51
5 janv. 2009 à 12:51
5 janv. 2009 à 12:40
5 janv. 2009 à 10:55
J'avais fait un petit article sur les performances php ya un moment, si ca intéresse certaines personnes :
http://blog.reflectiv.net/2008/07/29/optimisation-php/
5 janv. 2009 à 10:04
5 janv. 2009 à 09:52
Quand j'ai vu un "Abstraction [sgbd]", je me suis dit "Encore !!". J'ai donc regardé (un peu en travers, je doit l'admettre) quel en était le but, la qualité, etc.
Je rejoindrais Webdeb et Neige sur le fait que c'est vraiment bien codé, commenté et bien structuré.
Après, pour un avis personnel, je dirai que je ne suis pas pour imposer certaines méthodes dans une classe, tel que "listTable". En effet, je préfère personnellement faire des classes à usage spécifique (une classe Pdo_Show pour effectuer la plupart des requetes "SHOW ..." par exemple). Mais cela n'engage que moi et chacun à son point de vue, c'est ce qui fait notre diversité :)
Cependant, histoire de faire mon pointilleux, j'attirerais ton attention sur un partie de ton code, là ou tu utilise array_key_exists dans tes conditions ternaires : array_key_exists('adapter', $aParams)) ? .... : .... ;
Je te conseil d'utiliser un isset ($aParams['adapter']) qui est beaucoup plus rapide (isset n'est pas réellement une fonction mais une structure du langage, donc beaucoup plus performant).
4 janv. 2009 à 18:39
Quand tu utilise la fatory il vérifie si la classe passé en paramètre etends la classe PdoManager
4 janv. 2009 à 18:16
"Pour rajouter le support d'autre bdd il suffit par exemple de créer une class PdoMssql et d'y implémenter les méthodes obligatoires."
Alors ajoute les interfaces informant sur ces méthodes obligatoires justement
4 janv. 2009 à 15:57
Merci pour vos commentaire ça fait plaisir.
Je suis en train de faire une petite mise a jour pour pouvooir lancer une action sur certaine méthode de pdo
Par exemple logger des requetes.
Je met la source a jour des que c'est fini
4 janv. 2009 à 14:06
4 janv. 2009 à 13:45
Tu devrais préciser que la version de PHP requise est 5.3, parce que sinon, y'en a pas mal qui vont pas comprendre les messages d'erreurs alors qu'ils sont avec la dernière version stable ;)
C'est la première source que je vois qui nécessite PHP5.3 : ça fait plaisir, mais ça pourrait être intéressant de faire fonctionner ça sur PHP 5.2.x
J'ai pas regardé le code en détail (comme toujours... désolé... :/ ) mais avoir un commentaire comme ça de la part de WebDeb, c'est une belle performance. Donc rien que pour ça, chapeau !
@WebDeb : euh je ne te critique pas, hein, c'est juste que comme tu es exigeant (et c'est une qualité pour moi), il est rare que tu laisses un commentaire qui laisse penser que la source est parfaite... D'où la performance...
Et bonne année tout ça tout ça *=/:-)
4 janv. 2009 à 12:54