Bonjour,

Voilà je suis en train de refaire toute l'architecture dev de mon site, et dans un soucis d'optimisation de mes scripts finaux, j'ai dans l'idée de laisser mes classes gérer elles-mêmes leur connexion à leur base de référence.

Par exemple :
ma classe utilisateur ouvrira (via __construct) et fermera (via __destruct) la connexion à la base utilisateur dont elle a besoin pour travailler.
ma classe newsletters idem pour une connexion à la base newsletters
etc ...

Les questions que je me pose sont :
- Si je fais appel à 3 classes dans mon script final, cela va ouvrir 3 connexions à la base, donc est-ce que je ne risque pas de surcharger ma base avec ce système ? Sachant biensûr que je ne serai pas le seul sur ce site, cela va sans dire
- Question surement basique, mais pour laquelle je n'ai pas de réponse, à quel moment le __destruct d'une classe est-il lancé ? A la fin du script qui fait référence à la classe, ou lorsque la classe n'est plus utilisée dans le script ?

Par exemple, si j'initialise ma classe utilisateur à la ligne 1 et ma classe newsletters à la ligne 2.
J'en ai fini avec ma classe utilisateur à la ligne 60 et ma classe newsletters à la fin de mon script ligne 120. Le __destruct d'utilisateur sera-t-il exécuté à la ligne 60 ou 120 ?

Et je me retrouve aussi dans une situation à la connexion se fait à la même base pour une groupe de classe, mais sur des tables différentes biensûr. Et si le système était valide pour des bases différentes, l'est-il toujours pour des tables différentes ?

Merci d'avance pour vos réponses.

Personnellement, je te déconseille l'ouverture/fermerture de connexion à ta base de données à l'instanciation de l'objet, et je n'ai pas de meilleur exemple que celui que tu donnes : 3 classes vont effectivement ouvrir 3 connexions, mais pire encore, une seule classe instanciée 10 fois va ouvrir 10 connexions... si jamais par exemple, pour une quelconque raison, tu avais besoin d'un tableau d'utilisateurs....

Bref, à moins d'en avoir besoin, mieux vaut une seule connexion (d'autant plus que la connexion à la base de données est généralement un traitement assez lourd, donc moins tu pourras y faire appel, mieux ton script se portera )

Quoi qu'il en soit, concernant l'appel au __destruct, il se fait lorsque l'objet est explicitement détruit, ou bien lorsqu'il n'y a plus aucune référence à ton objet (effacées à coup de unset ou de = null), ou enfin, à la fin de l'exécution de ton script pour les instances restantes.

Donc pour répondre à ta question, si tu détruit ton objet ligne 60, ta connexion sera refermée. Si tu supprimes la dernière référence à ton objet à la ligne 60, ta connexion ne tardera pas à se refermer (je suis pas certain que ce soit immédiat), et si tu ne fais rien, elle sera refermée après la ligne 120 quand php fera le ménage

Je trouve l'idée d'ouverture intéressante... elle est réalisable à l'aide du Design Pattern "Singleton" et à la notion de variable "statique".

Par contre je déconseille la fermeture ! Ou alors une ouverture persistante et une fermeture.

Pourquoi pas une ouverture et une fermeture à chaque fois ?

Car l'ouverture de la connexion à la base de données à chaque fois et parfois plus longue que la (les) requête(s) elle(s)-même.

C'est mon avis mais nous pouvons en débattre ici.

Personnellement, je te déconseille l'ouverture/fermerture de connexion à ta base de données à l'instanciation de l'objet, et je n'ai pas de meilleur exemple que celui que tu donnes : 3 classes vont effectivement ouvrir 3 connexions, mais pire encore, une seule classe instanciée 10 fois va ouvrir 10 connexions... si jamais par exemple, pour une quelconque raison, tu avais besoin d'un tableau d'utilisateurs....

Ce n'est pas vraiment le tableau qui m'inquiète, avec des méthodes appropriées je peux m'assurer de n'ouvrir que deux connexions, si je ne vais chercher des infos que dans deux bases. Disons que je suis pratiquement certain de n'avoir pas plus de 5 connexions à faire dans un même script. Mais 5 ça commence à chiffrer... Mais j'avoue que l'idée que ce soit la connexion qui soit gourmande, et moins le fait de garder une connexion ouverte, va me faire changer mon fusil d'épaule.

Quoi qu'il en soit, concernant l'appel au __destruct, il se fait lorsque l'objet est explicitement détruit, ou bien lorsqu'il n'y a plus aucune référence à ton objet (effacées à coup de unset ou de = null), ou enfin, à la fin de l'exécution de ton script pour les instances restantes.

Donc pour répondre à ta question, si tu détruit ton objet ligne 60, ta connexion sera refermée. Si tu supprimes la dernière référence à ton objet à la ligne 60, ta connexion ne tardera pas à se refermer (je suis pas certain que ce soit immédiat), et si tu ne fais rien, elle sera refermée après la ligne 120 quand php fera le ménage

Ok merci pour ces infos c'est bon à savoir.

Je trouve l'idée d'ouverture intéressante... elle est réalisable à l'aide du Design Pattern "Singleton" et à la notion de variable "statique".

Je vais regarder ça en détail, voir si ça peut m'aider, je n'ai pas encore beaucoup de notion sur le singleton. Merci pour la piste.

Par contre je déconseille la fermeture ! Ou alors une ouverture persistante et une fermeture.

Pourquoi pas une ouverture et une fermeture à chaque fois ?

Car l'ouverture de la connexion à la base de données à chaque fois et parfois plus longue que la (les) requête(s) elle(s)-même.

J'avoue ne pas trop saisir, qu'est-ce que tu conseils comme ouverture/fermeture et que tu déconseilles comme ouverture/fermeture ?

La notion de singleton fait en sorte de ne pouvoir instancier qu'une seule occurence de classe (ici la connexion à la bdd), la notion de variable statique permet de stocker et de retourner l'identifiant de cette unique connexion.

Si ce mécanisme est mis en place, nous pouvons faire des ouvertures et des fermetures dans toutes les autres classes qui ont besoin de la connexion à la base de donnée MAIS ....

La durée d'ouverture de la connexion à la base de données et parfois plus longue que la durée des requêtes elles-même.


Il faut donc que la connexion soit persistante ou alors se passer de la fermeture de la connexion...

La notion de singleton fait en sorte de ne pouvoir instancier qu'une seule occurence de classe (ici la connexion à la bdd), la notion de variable statique permet de stocker et de retourner l'identifiant de cette unique connexion.

Si ce mécanisme est mis en place, nous pouvons faire des ouvertures et des fermetures dans toutes les autres classes qui ont besoin de la connexion à la base de donnée MAIS ....

La durée d'ouverture de la connexion à la base de données et parfois plus longue que la durée des requêtes elles-même.

Il faut donc que la connexion soit persistante ou alors se passer de la fermeture de la connexion...

Alors ça ça peut-être ma solution, merci Sedril, je vais tester ça pour voir.