CLASSE PHP4 DE CONNEXION À UN SGBD
gr43
Messages postés
95
Date d'inscription
mardi 20 mai 2008
Statut
Membre
Dernière intervention
8 septembre 2010
-
21 mai 2008 à 15:35
gr43 Messages postés 95 Date d'inscription mardi 20 mai 2008 Statut Membre Dernière intervention 8 septembre 2010 - 11 juin 2008 à 13:47
gr43 Messages postés 95 Date d'inscription mardi 20 mai 2008 Statut Membre Dernière intervention 8 septembre 2010 - 11 juin 2008 à 13:47
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/46721-classe-php4-de-connexion-a-un-sgbd
https://codes-sources.commentcamarche.net/source/46721-classe-php4-de-connexion-a-un-sgbd
11 juin 2008 à 13:47
A plus
11 juin 2008 à 12:16
Pour moi, c'est au minimum une méthode statique. Mais ça pourrait aussi être une classe statique.
$base = BASE::load (NOM, MDP, BASE, SERVEUR, SGBD);
La méthode statique load est une factory : c'est elle qui va instancier la bonne classe en fonction de ce que tu lui demandes.
"je suis en PHP5 mais le serveur est en PHP4"
T'as pas à avoir honte : je suis dans le même cas, au boulot (on choisit pas tout, et surtout, faire des mises à jours aussi importantes sur plusieurs serveurs en prod, ça nécessite de faire quelques tests, et pour ça, faut avoir du temps)
10 juin 2008 à 18:25
Tchao
10 juin 2008 à 18:20
je pensais à une factory du type :(vue sur php.net)
class Exemple
{
// La méthode de paramètre d'usine
public static function factory($type)
{
if (include_once 'Drivers/' . $type . '.php') {
$classname = 'Driver_' . $type;
return new $classname;
} else {
throw new Exception ('Driver non trouvé');
}
}
}
Ce qui m'éviterai d'inclure les différentes classes dans mon fichier d'inclusion mais seulement la classe mère, elle même se chargeant de charger le driver du sgbd souhaité lors d'une instanciation.
Ouais, désolé je plane pour E_STRCIT mais c'est par ce qu'en local (je suis quand même pas tout à fait maso), je suis en PHP5 mais le serveur est en PHP5. Mais j'essaye de coder avec le moins de syntaxe obsolète possible... (je sais bonne blague pour du PHP4).
10 juin 2008 à 14:09
"Mais par contre, autant utilisé une factory pour permettre le chargement à la volée de la sous-classe utilisé, non?'"
Ca ne revient pas à ça, c'est exactement ça... La méthode statique load est la factory de ta classe dans ton cas.
"Par contre appelée la méthode load de façon static alors qu'elle n'est pas déclarée static car PHP4, cela me fait une erreur E_STRICT sur PHP5"
Autant écrire une classe PHP4 et une classe PHP5... Quitte à utiliser PHP5, autant l'utiliser pour de vrai, plutôt que de se limiter à une utilisation archaïque.
10 juin 2008 à 11:38
10 juin 2008 à 11:34
Pour les trigger_error, je vais potasser tout çà, en tous cas merci des liens car ils sont bien utiles. Je t'avoue que je suis un peu léger niveau connaissance.
Si je peux me permettre une petite question, je ne vois pas trop la différence entre méthode à portée de classe et méthode privée?
Merci encore de tes remarques constructives et à plus
9 juin 2008 à 19:06
http://fr2.php.net/manual/fr/language.oop5.paamayim-nekudotayim.php
Tu peux faire des fonctions statiques appellées sans instancier la classe ce qui permet d'encapsuler dans des classes des fonctions indépendantes. L'avatage c'est que quand tu lis ton code c'est plus lisible, et tu sais où trouver la fonction. Les singleton fonctionnent comme ça - un exemple en php 4 : http://zefredz.frimouvy.org/dotclear/index.php?2007/02/18/160-forcer-un-singleton-en-php4
Un ptit commentaire pour la gestion des erreurs. Il serais préférable tu que généres tes erreurs à partir de la fonction trigger_error car elle est utilisée par le framework php - tu peux les logguer et bien plus. Du coup jettes un coup d'oeil sur http://fr2.php.net/manual/fr/function.set-error-handler.php, tu peux facilement faire un singleton gérant l'abstraction des erreurs générées par ta partie de code et les autres erreurs système. L'avantage est de centraliser la gestion des erreurs, voire même de la surcharger pour la spécialiser selon cas d'utilisation. Ca serait un réel plus par rapport à tout ce qui existe déjà.
Bonne continuation
9 juin 2008 à 14:45
C'est vrai que j'aime bien le principe de la fonction car elle permet de ne pas avoir à modifier les appels aux constructeurs dans les différents scripts lors de la migration vers un autre SGBD. Pour la gestion de plusieurs connexions on peut alors modifier la constante par une variable. Puis, on peut toujours utiliser un patterns.
Par contre, je trouve ton exemple sympa puisqu'il permet d'obtenir une erreur si on instancie un objet d'une classe inexistante. Merci de vos remarques, je vais me pencher sur les design patterns.
4 juin 2008 à 23:47
Pour l'interfaçage je rejoins Akhe, c'est facile à moindre frais, même en PHP4. Et c'est bien plus élégant comme son exemple le montre.
4 juin 2008 à 23:43
heu oui...travailler avec plusieurs connexions peut-être carrément nécessaire. Sans parler de différents serveurs (bien que ce soit aussi mon cas, comme pour Neige apparemment : synchroniser 2 serveurs DB, par exemple...), on peut aussi avoir un serveur, et plusieurs DB... et une connexion par DB avec chacune leurs droits (histoire d'éviter les truncate malheureux....).
Non, jouer avec plusieurs connexions n'est peut-être pas une habitude dans le dév amateur, mais c'est carrément une quasi obligation dans le dév pro.
4 juin 2008 à 23:40
Tu développes en objet, donc tu dois avoir une approche objet donc une approche sur l'instanciation de ta classe. Dans ton modéle tu proposes une fonction, c'est pas forcément bon en POO.
Tu aurais très bien pu créer une classe de type proxy, exploser un peu plus ton modéle...brèf améliorer ton modèle objet. Je te conseille de consulter le tuto de Malalam sur les design patterns il explique tout ça et c'est réalisable en PHP4.
En tout cas dans l'état de ton code tu ne peux appeller qu'une seule fois la fonction de connexion et le type de base de données ne devrait pas être définit ainsi. Juste un exemple équivalent :
class BASE {
...
function load($base, $host 'localhost', $user 'root', $pwd = '', $type = 'mysql') {
$class = 'BASE_'.$type;
if (class_exists($class)) {
return new $class($user, $pwd, $base, $host);
} else {
// GENERER UNE ERREUR
}
}
...
}
et au niveau utilisation ça donnerais :
$dbMySQL = BASE::load('test', 'localhost', 'root', 'pwd', 'mysql');
$dbPostGRE = BASE::load('test', 'localhost', 'root', 'pwd', 'postgre');
...etc...
Bonne prog et a+,
akh
4 juin 2008 à 11:37
Des fois, on a besoin de se connecter à plusieurs serveurs, parce que le fournisseur d'une entreprise n'a pas forcément envie de partager son serveur et sa base de données avec tous ses clients. C'est qu'un exemple...
3 juin 2008 à 22:04
1 juin 2008 à 14:14
http://www.phpcs.com/tutoriaux/ABSTRACTION-PHP_845.aspx
1 juin 2008 à 13:27
Sinon ligne 33 / 34 tu pourrait mettre :
function connect($login, $motDePasse, $base, $serveur) { trigger_error('You class must define a connect function !', E_USER_ERROR); }
function exe ($requete) { trigger_error('You class must define a exe function !', E_USER_ERROR); }
Cela ressemblerais un peu plus à de l'abstraction au cas où la classe ne serais pas construite correctement. Le désavantage c'est que l'erreur serais visible qu'à l'utilisation des fonctions...
22 mai 2008 à 14:26
Maintenant, si ce que Markus dit est équivoque, ce qu'il énonce reste quand même (à mon avis en tout cas) une règle de "best practice".
Il y a ce que permet PHP techniquement et ce qui fait qu'un code est "bien codé".
22 mai 2008 à 12:39
Dans le cas d'une exception, c'est différent... : on tombe sur un cas exceptionnel. Ce qui ne veut pas dire que tout doit s'arrêter : seulement le traitement que l'on essaye (d'où "try"). Je continue de penser que Marcus est équivoque dans ce qu'il dit, quand bien même dans les faits, mes catch sont généralement à la fin du script (j'ai rarement plus d'un traitement par script, en fait).
22 mai 2008 à 11:36
"Les exceptions
ne terminent pas un script mais elles permettent un traitement particulier, non?"
Si. Une exception termine un script. Elle ne redonne pas la main et NE DOIT PAS servir à effectuer un traitement différent du site.
La règle numéro 2 énoncée par Markus Börger dans son document "SPL for the masses" dit :
"Never use exceptions for control flow"
http://somabo.de/talks/200504_php_quebec_spl_for_the_masses.pdf (page 38)
22 mai 2008 à 10:58
22 mai 2008 à 07:42
sinon, son code, je ne vois pas trop ce que tu lui reproches malalam. Enfin pour un code en php4, je vois difficilement comment faire mieux. Ce design :
driverinterface (ou classe abstraite)
drivermysql <---- driverinterface
driverpostgre <---- driverinterface
connections (driverinterface)
c'est un classique
bon, sauf que la, concection est une fonction alors qu'en general, connections est soit un singleton soit un muliton, (mais pas toujours une factory)
sinon, renvoyer false, pour pouvoir faire un ===false, pour contourner les exceptions, c'est comme faire des monades. Et les monades sont des trucs que les gens font dans des langages propres pour eviter les Exceptions (Exception etant un effet de bord...)
Mais en php, on a pas l'habitude de se preoccuper des effets de bords (surtout dans une classe comme celle-ci), donc les monades n'ont pas trop leur place.
Bref, si tu pouvais utiliser les Exceptions, ca serait bien, mais si tu veux rester en php4, alors ca me semble une bonne solution...
Bref, faire du php4 en 2008, c'est mauvais, mais pour du php4, moi je trouve que cette classe tient debout.
21 mai 2008 à 23:57
PDO ne répond pas à tout. C'est pour ça que sur ce code, j'insistais sur l'originalité des fonctionnalités. Si on doit faire une classe d'abstraction DB, il faut proposer des fonctionnalités, des simplifications sympas, utiles, et originales. Sinon en effet, autant utiliser PDO.
21 mai 2008 à 23:46
En fait, depuis PDO justement, je ne vois plus l'intérêt des classes d'abstraction justement, c'est ce que je voulais dire...
21 mai 2008 à 22:28
en tout cas merci de ses explications.
21 mai 2008 à 22:03
21 mai 2008 à 21:59
21 mai 2008 à 21:36
ne terminent pas un script mais elles permettent un traitement particulier, non? Désolé de te prendre la tête des deux côtés (forum et sources).
21 mai 2008 à 21:31
Comment ça se fait que tu n'aies pas parlé de PHP5.1 et de PDO?
Je ne sais que dire...
21 mai 2008 à 20:29
Sinon, un vrai gestionnaire d'erreur personnalisée ferait l'affaire mais il ne doit pas être lié à ta classe. Il doit être global dans ce cas, donc c'est une autre source.
21 mai 2008 à 20:21
Pour le php4 je n'est pas le choix vu le serveur.
Pour le
tu es dur car il y en un sur 2. C'est un de trop c'est vrai. Par contre pour le reste tu as tout à fait raison et je m'y attèle de ce pas. Je voulais juste savoir si je n'avais pas fait d'erreur de syntaxe car je débute en POO et PHP4 c'est un peu la m...
J'aurrai peut être dû la poster en forum, désolé.
Pour les erreurs avec une gestion personnalisée en PHP4, est on obligé de les avoirs, à part en modifiant les E_WARNING ou avec un debug_backtrace() dans la fonction car les @ ne suffisent pas ou encore en stoppant temporairement la gestion perso? Je ne vois comment faire autrement car pas d'exception.
Merci encore.
21 mai 2008 à 19:39
je suis embêté pour commenter ton code. Je pense la même chose que Dépression. Déjà.
Ensuite, il est vraiment très basique. Je pourrais louer le débutant qui fait de l'abstraction en php4. La base est bonne. Il y a pas mal de problèmes quand même.
Bon...vaguement, je ne vais pas m'éterniser :
- tu manques de constance dans l'écriture du code : choisis entre le français et l'anglais!
- ton code balancera les erreurs PHP de toute manière selon l'error_reporting, dans certains cas. Pas dans d'autres. Cela rejoint le manque de constance.
- avec juste un
tu parviens à nous imposer du html 3.2 à l'heure du xhtml...c'est quand même dommage. C'était pas la mort d'écrire
au lieu de
...
- mysql_pconnect()...et si je ne veux pas de connexion persistante, je fais quoi...? Je modifie ta classe? A quoi bon faire de l'objet dans ce cas ? Une classe d'abstraction DB doit au moins donner un choix. Tu n'en donnes aucun.
- ta classe ne fait qu'envelopper des fonctions existantes : elle ne propose rien de nouveau, ni aucune facilité. Si au moins tu nous proposais différentes DB, mais là en l'occurence, non, il faut les coder soi-même. Dans ce cas, tu aurais pu au moins donner quelques fonctionnalités nouvelles, nous permettre de faire en un appel ce qui prend plusieurs lignes de code sans classe (renvoyer la clef primaire d'une table par exemple ? Chercher si une table existe ? Une bdd ? Un champ ? etc...).
Bref...ce n'est pas MAL codé. C'est propre, ça va. C'est correct, quoi. Mais ça n'apporte vraiment rien. Pas même à toi, à part le plaisir de le coder et du coup de t'améliorer. Mais à nous...? Rien.
Tu devrais approfondir, vraiment beaucoup. Et même si ton but n'est que de t'améliorer et d'avoir des critiques : vas plus loin...parce que là le code est tellement basique qu'il n'y a pas grand chose à en dire : c'est ok. Voilà. En même temps, tu n'as pas pris de risque.
21 mai 2008 à 15:41
21 mai 2008 à 15:35