tinalestate
Messages postés4Date d'inscriptionmercredi 10 décembre 2008StatutMembreDernière intervention30 septembre 2017 11 sept. 2011 à 18:21
Un bel exemple de savoir mais c se compliquer la vie ...
et, terreaultguy, config.ini c ton propre fichier où tu indiques login/ password de ta connexion Mysql à toi :))
terreaultguy
Messages postés1Date d'inscriptiondimanche 13 mai 2007StatutMembreDernière intervention11 septembre 2011 11 sept. 2011 à 15:15
Bonjour
La premiere de code est:
include 'config.php';
mais dans les explications ou le .zip ce fichier n'existe pas
Est-ce un générique ou est particulier a cette example.
Quand je récolte des exemples par d'autres les include sont souvent fournie
Merci,
Guy
devil_may_cry
Messages postés194Date d'inscriptiondimanche 18 mars 2007StatutMembreDernière intervention11 juillet 2015 10 sept. 2011 à 18:11
j'avais pas encore explorer son utilisation dans un wrapper donc je ne saurai en mesure de te donné une réponse sur le sujet
cod57
Messages postés1653Date d'inscriptiondimanche 7 septembre 2008StatutMembreDernière intervention11 septembre 201319 10 sept. 2011 à 17:25
j'ai lu ça avant dans le manuel
http://www.php.net/manual/fr/language.oop5.patterns.php Le pattern Singleton est l'un des plus controversés. Les critiques indiquent que le singleton crée un contexte global dans l'application et couple fortement le singleton à d'autres classes. Ceci mène vers des dépendances cachées et des effets de bord désagréables, le code devient ainsi plus difficile à maintenir et à tester.
Les critiques pointent aussi l'inutilité d'un singleton dans un environnement isolé comme PHP où les objets ne sont pas persistents entre les requêtes. Il est plus simple et propre de créer son graphe d'objets en utilisant des monteurs ou des fabriques, en début de requête.
Les singletons violent aussi plusieurs principes "SOLID" et la loi de Demeter. Les singletons ne peuvent être sérialisés. Il ne peuvent être surchargés (avant PHP 5.3) et ne seront pas nettoyés par le collecteur car une instance est toujours présente en mémoire, dans le singleton lui-même.
pensez vous que le singleton soit sur dans un wrapper quelconque ?
devil_may_cry
Messages postés194Date d'inscriptiondimanche 18 mars 2007StatutMembreDernière intervention11 juillet 2015 10 sept. 2011 à 17:06
"Je ne crache pas sur ton boulot, ce n'est pas mon genre"
il y a pas de souci on est juste entrain de confronter nos deux point de vue il y a de mal en ça
une des raisons est qu'il s’avère que parfois certain hébergeur n'active pas l'extension PDO pour leur pack free ce qui est fréquent donc pour moi il ne s'agit plus dans ce cas ci de réinventer la roue mais plutôt une manière d'avoir une approche objet des fonctions native mysql_*
je comprend bien ton point de vue !!
phpAnonyme
Messages postés392Date d'inscriptionmercredi 28 octobre 2009StatutMembreDernière intervention23 mars 201255 10 sept. 2011 à 16:48
Je ne vois pas en crois ta classe simplifie la gestion des requêtes préparés, puisque tu sembles te baser sur PDO et PDOSTATEMENT. Ce que je veux te faire comprendre c'est que tu réinventes PDO avec des fonctions mysql_*. D'où à mon sens il n'y a pas de grand intérêt. Je ne crache pas sur ton boulot, ce n'est pas mon genre, mais je ne comprend pas le pourquoi.
devil_may_cry
Messages postés194Date d'inscriptiondimanche 18 mars 2007StatutMembreDernière intervention11 juillet 2015 10 sept. 2011 à 16:32
si je passe le constructeur en public on pourra donc avoir plusieurs instance de la class en utilisant new ce qui faussera mon approche singleton qui est la pour éviter cela :)
cod57
Messages postés1653Date d'inscriptiondimanche 7 septembre 2008StatutMembreDernière intervention11 septembre 201319 10 sept. 2011 à 16:18
Bonjour
pourquoi n'utilises tu pas le constructeur en public ?
et passes tu par connect
devil_may_cry
Messages postés194Date d'inscriptiondimanche 18 mars 2007StatutMembreDernière intervention11 juillet 2015 10 sept. 2011 à 14:46
Merci d'avoir pris le temps de jeter un coup d’œil !
je suis peut être d'accord avec toi sur le faite que les fonctions existe en native mais le fait que la class n'est pas intéressante je ne crois pas qu'on est en phase sur ça puisque la class simplifie la gestion des requête préparer même si cela existe avec l'extension mysqli_* en plus d'offrir deux mode de gestion d'erreur (exception,warning)et met en évidence l'approche singleton.
phpAnonyme
Messages postés392Date d'inscriptionmercredi 28 octobre 2009StatutMembreDernière intervention23 mars 201255 10 sept. 2011 à 05:58
Avec un coup d'oeil rapide; Ta classe n'est pas vraiment intéressante dans le sens où celà ressemble plus à une translation des fonctions mysql_* en PHP>5. En somme les fonctions de ta classe existe déjà en natives. Peut-être que c'était le but ?
12 sept. 2011 à 01:48
dans config.php il y'avait ca
$dbcfg['host'] = 'localhost';
$dbcfg['database'] = 'base';
$dbcfg['user'] = 'root';
$dbcfg['passsword'] = '';
11 sept. 2011 à 18:21
et, terreaultguy, config.ini c ton propre fichier où tu indiques login/ password de ta connexion Mysql à toi :))
11 sept. 2011 à 15:15
La premiere de code est:
include 'config.php';
mais dans les explications ou le .zip ce fichier n'existe pas
Est-ce un générique ou est particulier a cette example.
Quand je récolte des exemples par d'autres les include sont souvent fournie
Merci,
Guy
10 sept. 2011 à 18:11
10 sept. 2011 à 17:25
http://www.php.net/manual/fr/language.oop5.patterns.php
Le pattern Singleton est l'un des plus controversés. Les critiques indiquent que le singleton crée un contexte global dans l'application et couple fortement le singleton à d'autres classes. Ceci mène vers des dépendances cachées et des effets de bord désagréables, le code devient ainsi plus difficile à maintenir et à tester.
Les critiques pointent aussi l'inutilité d'un singleton dans un environnement isolé comme PHP où les objets ne sont pas persistents entre les requêtes. Il est plus simple et propre de créer son graphe d'objets en utilisant des monteurs ou des fabriques, en début de requête.
Les singletons violent aussi plusieurs principes "SOLID" et la loi de Demeter. Les singletons ne peuvent être sérialisés. Il ne peuvent être surchargés (avant PHP 5.3) et ne seront pas nettoyés par le collecteur car une instance est toujours présente en mémoire, dans le singleton lui-même.
pensez vous que le singleton soit sur dans un wrapper quelconque ?
10 sept. 2011 à 17:06
il y a pas de souci on est juste entrain de confronter nos deux point de vue il y a de mal en ça
une des raisons est qu'il s’avère que parfois certain hébergeur n'active pas l'extension PDO pour leur pack free ce qui est fréquent donc pour moi il ne s'agit plus dans ce cas ci de réinventer la roue mais plutôt une manière d'avoir une approche objet des fonctions native mysql_*
je comprend bien ton point de vue !!
10 sept. 2011 à 16:48
10 sept. 2011 à 16:32
10 sept. 2011 à 16:18
pourquoi n'utilises tu pas le constructeur en public ?
et passes tu par connect
10 sept. 2011 à 14:46
je suis peut être d'accord avec toi sur le faite que les fonctions existe en native mais le fait que la class n'est pas intéressante je ne crois pas qu'on est en phase sur ça puisque la class simplifie la gestion des requête préparer même si cela existe avec l'extension mysqli_* en plus d'offrir deux mode de gestion d'erreur (exception,warning)et met en évidence l'approche singleton.
10 sept. 2011 à 05:58