PHP5 CLASSE GÉNÉRIQUE GESTION ROUTINES MYSQL

Commentaire de malalam le 18/01/2007 08:23:15 administrateur CS

Hello,

faudrait que je regarde en détail, mais j'ai des questions et des remarques, en vrac, sans aller chercher trop loin :
Pourquoi appelles-tu tes méthodes privées non statiques via self::maMethode () ?
Tu devrais laisser le choix d'utiliser ou non ton bench dans la méthode query. Ca, moi, je l'utilise en dév, mais pas en prod, c'est du temps et des ressources perdues pour rien.
Un tableau de log d'erreurs aurait été mieux venu, en statique pourquoi pas, référencé par la ressource de connexion et la requête. Ca faciliterait le suivi et la sauvegarde des logs, le cas échéant.
Je ne vois pas l'intérêt de forcer par défaut les paramètres de connexion. On aurait même pu imaginer une seule instance de ton objet gérant plusieurs connexions. Pourquoi pas.
Quant tu codes en POO, autant coder de manière stricte :
if(stristr($this->query, 'select') == true)
ça, ce n'est pas strict du tout, c'est même du laisser aller :
if(stristr($this->query, 'select') === true)
C'est un détail dans ce cas-ci, mais ça peut ne pas l'être dans d'autres cas.
Ensuite, je n'aurais pas codé ça comme ça mais bon, là...c'est de la préférence.
Plus largement, tu devrais utiliser les exceptions pour gérer tes erreurs.

Bref, je dois aller bosser, donc ma dernière remarque est moins gentille : qu'apporte ta classe ?   Pourquoi l'utiliser plutôt que les fonctions mysql_* de php, ou mysqli ?
Il n'y a pas d'abstraction, tu ne facilites pas l'utilisation, tu obliges à mixer les méthodes de ta classe avec les fonctions mysql de base, tu n'apportes pas de nouvelles fonctionnalités.

Bref, ton code est clair, agréable à lire, mais y a du boulot, selon moi. Tant pour le code en lui-même que pour son utilité.

Commentaire de malalam le 18/01/2007 14:04:54 administrateur CS

J'avais même pas noté qu'il forçait une instance pour chaque requête; c'est effectivement une très mauvaise idée.

Commentaire de oxxo le 18/01/2007 17:51:25

Je vous aime ! Je sens que je vais progresser avec vous.
Alors je reprends dans l'ordre :

"Pourquoi appelles-tu tes méthodes privées non statiques via self::maMethode () ?"

=> Comment devrais-je les appeler ? "maMethode()", tout simplement ?

"Tu devrais laisser le choix d'utiliser ou non ton bench dans la méthode query"

=> Tout à fait d'accord. Et je prends note pour les logs.

"Je ne vois pas l'intérêt de forcer par défaut les paramètres de connexion."

=> Et bien parce que je trouve cela plus simple, dans la majorité des cas, je n'utilise qu'une seule bdd sur un seul et même serveur. Le fait de le définir dans la classe me permet le cas échéant de ne modifier que la valeur par défaut de ces attributs sans avoir a rechercher dans la masse des autres fichiers les endroit ou j'initialise une connexion. Question de facilité donc et de maintenance du code. Tout en gardant la possibilité de se connecter à un autre serveur …

"Quant tu codes en POO, autant coder de manière stricte. === et non =="

=> Quelle est la différence entre if($a == 'ok') et if($a === 'ok') ? Merci de m'éclairer sur ce point.

"tu devrais utiliser les exceptions pour gérer tes erreurs."

=> Tout à fait d'accord, je prends note.

Voila pour l'essentiel, je prend donc bien note de vos remarques. Concernant le singleton, je procédais comme cela avant, je vois qu'apparemment c'est préférable de continuer sur cette voie.

Pour la prochaine version, corrigez moi si j'en oubli :

Une classe abstraite nommée "sgbd", ce qui permettra de dériver d'autres classes en fonction du type d'sgbd.

Une classe fille de sgbd nommée "mysql" sur le principe du singleton. Donc un seul objet mysql dans le script à qui j’envois toutes les requêtes. Economie de mémoire, effectivement, et de ligne de code.
Possibilité de bench, au choix de l’utilisateur avec logs.(un booléen à l’instanciation, génération des logs en xml…)
Et du coup, avec toutes ces modifs (réécriture complète devrais-je dire…),  je pense que la classe apportera des fonctionnalités intéressantes par rapport aux fonctions mysql_* de php, ou mysqli, pour répondre à ta question MALALAM. (qui plus est mysqli est loin d’être installer chez la majorité des hébergeurs…).

Je me mets au boulot et je vous montre tous ça, merci pour tous ces conseils.

Commentaire de oxxo le 18/01/2007 18:26:02

Ok, merci beaucoup.

Commentaire de oxxo le 19/01/2007 20:30:07

Merci d'aller dans mon sens MALALAM, en réécrivant la classe, j'ai effectivement eu des soucis pour me connecter à des bases différentes avec le singleton, mais j'ai réglé le problème.

Je poste une nouvelle source très prochainement.

Je tiens à vous remercier car je pense avoir bien progressé. La classe est déjà fonctionnelle, la je taff sur la génération des logs pour le bench et pour les erreurs.

Pourrais-tu me mettre sur la voie pour permettre ou non l'utilisation du singleton ?

Merci

Commentaire de kankrelune le 20/01/2007 09:59:48

moi mon singleton gère les multiple connection... .. . ;o)

je stock tout dans un tableau dont les index sont

$myObjectArray['dbType:serverName:dbName'] = $myObject;

si tu change de type de sgdb, de serveur ou de base le singleton instancie un nouvel objet tout en gardant les avantages du singleton... .. . ;o)

@ tchaOo°