Discussion :

[vodasan]

Bonjour,

Il m'arrive de faire des méthodes dans des classes contenant des requêtes. J'aimerais savoir quelle est la meilleur façon pour lui passer le pointeur de connexion. Global ? dans le constructeur ? Par une méthode ? Ou en paramètre de la ou les méthodes de la classe ?

[Fench]

Bonjour,

Si lors de la création de l'instance de ta classe, tu as forcement un 'pointeur de connexion' ou ressource , tu utilises les getteurs/setteurs pour initialiser une variable (avec une portée comme tu veux Private/Protected selon l'utilisation) de ta classe contenant ce pointeur.

Alors ton instance aura toujours une connexion ... oui mais, si cette ressource est fermé par une autre partie de script

Donc la solution adaptée, un script (ou une combinaison) va donner un résultat web et alors ouverture d'une ressource en début de traitement et fermeture avant l'affichage (Sinon pour éviter des problèmes, une ressource pour un des ensembles de traitement etc, ...)

[gene69]

perso j'initialise un objet BD en début de traitement et je le refile par référence à toutes les méthode utilisatrice (je n'aime ni global ni le fonctionnement "base par défaut" ). pour le côté fermeture des connexions c'est tout géré implicitement par php, mode feignasse... sauf dans de rare cas ou j'avais une base tierce et dont je sais que je ne vais plus avoir besoin.

[Benjamin Delespierre]

Global sûrement pas, c'est une très mauvaise pratique qui va introduire du couplage inutile.

Il te reste à choisir entre:

• public function __construct (PDO $pdo, ...)
• public function setConnection (PDO $pdo)
• public static function registerConnection (PDO $pdo)
• public function myMethod (PDO $pdo)

Ce choix va dépendre de la forme de ta classe et surtout de son rôle: si c'est une classe modèle (donc destiné à l’interaction avec les données de la bdd) alors, il y a fort à parier que beaucoup de ses méthodes auront besoin d'une connection active, donc garder une référence sur l'instance de PDO au sein de la classe (comme propriété d'instance ou de classe, à toi de voir) est une bonne idée. L'avantage à en faire une propriété statique (avec la troisième forme) c'est que tous les objets de la classe auront cette référence sans qu'on ait besoin de leur passer, c'est moins flexible mais si tu n'utilise qu'une seule connexion à la fois, ce sera bien.
Si au contraire ta classe est plus un métier ou un service et qu'elle n'a besoin d'effectuer des requêtes qu'occasionnellement, on peut envisager de passer l'instance PDO sur la méthode en question. Encore que la meilleure approche dans ce cas reste la délégation à une classe modèle.

Bref, ton problème est en fait l'un des plus ardus de la conception objet (à mon sens) à savoir: comment répartir les responsabilités entre nos classes. Il faut toujours faire attention à ne pas créer une galaxie de classes minimaliste qui n'ont plus vraiment de pertinence et il ne faut pas non plus créer des classes "couteau-suisse" faisant presque tout. Il faut avant tout que ce soit cohérent.

[ovh]

Pour aller encore plus loin dans le découplage, on peut utiliser le design pattern "data mapper", qui est le principe fondateur de l'ORM Hibernate en java et de l'ORM Doctrine 2 en PHP :

• Les classes modèles (entités) ignorent complètement l'aspect persistance, donc pas d'accès à un quelconque objet de connexion à la base ! Elles ne font "que" gérer leurs attributs (correspondant aux colonnes des tables en base) et méthodes métier.
• Les modèles peuvent être persistés et récupérés via une classe "repository", qui est la seule à avoir une connexion avec la base.

http://docs.doctrine-project.org/pro...g-started.html

Cette méthode, bien que semblant peu naturelle au premier abord, est pourtant une bonne pratique qui sépare la persistance du métier. On peut ainsi imaginer de changer complètement l'aspect persistance des données d'une appli en modifiant uniquement les repositories : non seulement passer d'un moteur de DB à un autre, mais aussi passer à un stockage xml ou bien à un webservice ! Tout cela en laissant intactes les classes de la couche métier.