CLASS MYSQL 5/PHP5 AVEC GESTION DES EXCEPTION ET DES REQUÊTES PRÉPARÉS
phpAnonyme
Messages postés
392
Date d'inscription
mercredi 28 octobre 2009
Statut
Membre
Dernière intervention
23 mars 2012
-
10 sept. 2011 à 05:58
devil_may_cry Messages postés 194 Date d'inscription dimanche 18 mars 2007 Statut Membre Dernière intervention 11 juillet 2015 - 12 sept. 2011 à 01:48
devil_may_cry Messages postés 194 Date d'inscription dimanche 18 mars 2007 Statut Membre Dernière intervention 11 juillet 2015 - 12 sept. 2011 à 01:48
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/53569-class-mysql-5-php5-avec-gestion-des-exception-et-des-requetes-prepares
https://codes-sources.commentcamarche.net/source/53569-class-mysql-5-php5-avec-gestion-des-exception-et-des-requetes-prepares
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