CLASSE DE CONNEXION MYSQL EN PHP5
cs_yoman64
Messages postés
592
Date d'inscription
samedi 19 janvier 2002
Statut
Membre
Dernière intervention
4 décembre 2008
-
22 févr. 2008 à 16:27
malalam Messages postés 10839 Date d'inscription lundi 24 février 2003 Statut Membre Dernière intervention 2 mars 2010 - 24 févr. 2008 à 14:12
malalam Messages postés 10839 Date d'inscription lundi 24 février 2003 Statut Membre Dernière intervention 2 mars 2010 - 24 févr. 2008 à 14:12
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/45819-classe-de-connexion-mysql-en-php5
https://codes-sources.commentcamarche.net/source/45819-classe-de-connexion-mysql-en-php5
24 févr. 2008 à 14:12
24 févr. 2008 à 13:46
private $var1, $var2, $var3;
et non
private $var1; $var2; $var3;
Chaque propriété et donc déclaré comme privé.
;) Mais je prend note de tes commentaires pour de future améliorations.
24 févr. 2008 à 10:48
bon, je me décide à commenter un peu aussi, après les modifications faites.
Difficile de parler d'un tel code en ne faisant référence qu'à la manière dont il est codé...sans parler de son intérêt.
Parce que...quel est l'intérêt de créer une classe surchargeant les fonctions/méthodes liées à notre db ? Ici, il n'est pas question d'abstraction : on prend uniquement mysql et on crée une classe avec des méthodes censées faciliter son utilisation.
Pourquoi pas...même si pour moi les deux seuls types de classes DB vraiment utilses sont :
- les classes permettant d'abstraire le moteur db utilisé
- les classes spécialisées (j'ai un objet "user", je lui adjoint des méthodes d'acces db spécialisées pour lui).
Maintenant, ajouter des fonctionnalités utiles facilitant l'accès à certaines choses à l'extension mysql, pourquoi pas...
Mais encore faut-il bien le faire.
1ère remarque : je ne comprends pas ta façon de déclarer la portée de tes méthodes/propriétés. C'est peut-être une notation que je ne connais pas en php hein...mais bon...j'en doute :
private
$var1;
$var2;
$var3;
Je suppose que tu veux dire que ces 3 propriétés sont privées...mais si c'est une notation existante, je ne la connaissais pas.
Dans ton code, à mon avis, seule ta première propriété est privée, les autres sont publiques, là.
Faciliter les fonctionnalités existantes et en ajouter :
- ton constructeur : autorise le à se connecter automatiquement, par défaut. Parce que là il me faut 2 lignes pour me connecter alors que j'ai donné toutes les infos nécessaires à l'instanciation de mon objet.
- retourneNbRequetes : ça, pour moi, c'est une fonctionnalité inutile. Dans le cadre d'un mode "debug", je veux bien l'avoir, avec en plus les requêtes en entier, et le temps qu'elles ont mis à s'exécuter. Mais dans le cadre d'un debug uniquement. A part ça, je ne vois pas...
- connexion : ok, sauf que je préfère séparer la connexion et la sélection de la db. Encore une fois, laisse le choix, en mettant par défaut (sans précision de ma part) la connexion directe au serveur sur la db passée en paramètres. Mais je dois pouvoir changer de db si je le veux...en gardant ma connexion.
- TabResSql : là, y a du boulot...si mysql_num_rows et mysql_fetch_assoc sont séparées, il y a une raison. Je n'ai pas forcément le besoin de faire appel systématiquement à mysql_num_rows, certes, comme te le disent les autres. Mais le problème pour moi n'est pas là : ta méthode renvoie un tableau tout prêt. Bien, pourquoi pas. C 'est une fonctionnalité absente de l'extension mysql, ça, donc ok. Mais un tableau a une taille...donc je peux si je veux vérifier sa taille via count() ou sizeof(), je n'ai absolument pas besoin que tu appelles mysql_num_rows(). Ainsi, soit je veux vérifier, soit je ne veux pas. D'autre part, SI tu veux l'utiliser...tu fais une erreur de coneception : puisque tu as cette données, pourquoi ne vas tu pas faire un mysql_fetch_assoc() QUE SI mysql_num_rows() renvoie quelque chose...? Tu économiserais des appels inutiles.
Pour continuer sur cette méthode : tu obliges à passer 2 variables (tu les prends par référence). Je me doute que tu connais return, et que tu l'as fait parce que tu avais 2 éléments différents à retourner. Néanmoins, cela m'oblige à définir ces 2 variables au préalable, ce qui me fait 3 lignes de code pour appeler ta méthode. Il y a un tas de façons de contourner ça.
Sans compter que tu obliges ici à récupérer les données d'une seule manière : un tableau indexé numériquement, dont chaque clef fait référence à un tableau indexé associativement. Ce qui serait réellement intéressant, c'est de pouvoir formatter le retour. Ma classe par exemple (dans sa dernière version, non présente ici) permet de récupérer les données normalement (indexées numériquement, associativement, ou les deux), mais aussi de faire des regroupements sur le 1er champ (id => array(valeurs), ou id => array(array(valeurs)), ou num => id => array(valeurs) etc...), ce qui permet de faire des choses que l'on ne peut pas faire en sql.
Encore une fois, à mon sens, tu ne devrais que faire un return $tab. Le mysql_num_rows() n'a rien à faire là.
- executeSql : même problème, tu forces l'utilisation d'une fonction dont on a pas forcément besoin.
Au final, ta classe n'apporte que peu de fonctionnalités intéressantes, et ne fait qu'ajouter de la lourdeur à l'utilisation de l'extension mysql. Tu n'apportes pas assez pour que ce soit intéressant (je sais pas moi : une méthode permettant de vérifier si une table existe, une permettant de retourner la définition d'une table, une permettant de savoir quel champ est la clef primaire de la table, etc...), et les idées éventuellement intéressantes sont mal implémentées.
Cherche plus loin ! C'est en utilisant une db en php qu'on finit par trouver des idées qui nous faciliterait la vie. Et on ne se facilite pas la vie en se contenant de créer une méthode "connect" qui ne fait qu'un "mysql_connect". Ca ne sert à rien. C'est comme créer une fonction say() qui ne ferait que remplacer echo. C'est inutile et ça fait plus travailler php pour rien.
Réflêchis plutôt à ce qui est vraiment long et pénible à faire sur une DB...et propose des méthodes qui facilitent ces choses.
22 févr. 2008 à 20:50
http://www.phpcs.com/codes/EXCEPTION-EXCEPTION-MYSQL-FILEEXCEPTION_43064.aspx
22 févr. 2008 à 20:38
22 févr. 2008 à 20:27
22 févr. 2008 à 20:16
Personnellement je laisse la source pour montrer aux autres ce qu'il est déconseillé de faire et pourquoi. Maintenant si Malalam passe par ici, peut-être la supprimera-t-il ?
@crocxx2 : Ton code peut-etre améliorer, tu peux arriver à quelque chose de très complet et tres utile. On ne te demande pas de nous sortir une abstraction de base de donnée, mais un système pouvant s'en approcher, plus performant que ton code actuel sera dans tous les cas meilleur.
Je compte sur toi ?
22 févr. 2008 à 20:02
22 févr. 2008 à 19:58
@crocxx2 : Comme l'a déjà été dit avant, les die sont déconseillés, et à remplacer par des throw new Exception (ou une exception personnalisée). Pourquoi ? Comme te l'a dit Yoman et Coucou, ta class ne doit pas retourner de html (comment je fait si j'utilise ta classe pour générer du pdf ?).
Par ailleur, au vue de ton code j'en déduit qu'il ne fonctionne uniquement sous Php5 (attributs private, méthodes magiques), mais malheureusement tu fait de la redondance avec ton code. La méthode TabResSQL boucle pour retourner un tableau, et ensuite dans ton code tu re parcours le tableau pour afficher les données. Tu fait travailler ton serveur plus que ce qu'il n'en faut ! Regarde du coté de la Spl et des codes déjà présents ici (la couche d'abstraction de Malalam, celle de Fhx et la mienne sont des bons exemples, pour ce cas là en tout cas ;)).
Par ailleur tu n'indique pas la portée de tes méthodes. Bon, tu me dira que c'est du publique implicitement, mais explicitement, c'est plus beau, plus simple, pérènne et surtout ca t'évite un casse tête quand tu relira ton code plus tard (sais-t-on jamais :p).
Enfin, donne des noms cohérents à tes fonctions (notament TabResSQL) et commente ton code.
22 févr. 2008 à 18:56
22 févr. 2008 à 18:18
Et puis dans la fonction ExecuteSQL, son role normallement devrait être d'executer une requete tout simplement, et de lancer une exception si on est en mode debug et que la requête échoue par exemple, pas de calculer le nombre de lignes affectées.
22 févr. 2008 à 17:59
22 févr. 2008 à 17:57
pourrais tu précisé un peu plus les optimisation et les fonctionnalité que je pourrait apporter?
J'ai aussi quelque question:
- Pourquoi les die() c'est mal?
- je vérifie le nombre de lignes que j'ai affecté pour vérifier qu'il n'y a pas d'erreur c'est mal de le faire a chaque fois?
Pas de soucis pour le commentaire, tend qu'il y a les explication je le prend pas mal. ;)
22 févr. 2008 à 16:27
De plus, dans ExecuteSQL pourquoi appel tu mysql_affected_rows ? Il est tout à fait possible qu'on en ait même pas besoin, ce qui ferait un appel de fonction pour rien.
Ce genre de code est souvent très utile quand on peut s'en servire comme singleton, ça élargie beaucoup son champs d'action si on gère un gros projet avec de multiples classes/modules.
Enfin bref, ça manque cruellement de fonctionnalité, d'optimisation (on peut tout refaire en 2-3 fois moin de lignes...) du déja vu et en beaucoup mieu. Je m'abstiens donc de noter.
Je sais, c'est un peu dur comme commentaire, mais c'est comme ça qu'on progresse, prends le pas mal :)