Bonjour � tous !

Avant de d�buter, d�sol� pour le titre, je suis demeur� 2 minutes le curseur dans la case et j'ai pas trouv� plus explicite.


Bon, ce qui m'am�ne � vous.

Le contexte:
J'ai un site, qui est un jeu, avec des centaines d'actions possibles. Chaque action est en fait une simple classe, avec une m�thode statique qui re�oit les objets requis en r�f�rence.

Exemple:
Code : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
 
class Member_Action_Perso_Soigner {
 
	public static function generatePage(&$tpl, &$db, &$session, &$account, &$perso)
 
	{
Jusque l�, "ca va" (enfin, � mes yeux ca va)

L� ou ca se corse, c'est au sujet de $db:
$db est en fait une Classe qui s'occupe de g�rer les rapports d'erreurs et les diverses statistiques, sans trop me compliquer l'utilisation normale le mysql:

Code : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
 
$result = $db->query('SELECT......');
Cette syntaxe est simple � utilis�e, et si jamais une requ�te plante, ma classe s'occupe de m'envoyer un email toute seule (par exemple).
Bref, elle m'est tr�s pratique. Et je vous l'explique pour ne pas que vous me disiez qu'elle est inutile

Le souci:
Mon action soigner interagi avec des $perso, qui repr�sente un personnage: Dans ce cas-ci, nous avons $perso (Le joueur), et le soign�, qui est instanci� dans la m�thode statique, afin de lui prodiguer les soins.

Si je veux changer les points de vie du personnage, j'ai un code qui ressemble � ceci:
Code : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
 
$victime->setPV($db, 34);
$perso->gainXP($db, 'soin', 3);
Et c'est l� que je trouve mes classes "intanciables" (Perso, Lieu, Item, etc.) peu intuitive d'utilisation: Parfois il faut passer &db, parfois non. Ce n'est pas toujours aussi �vident que dans cet exemple. J'aimerais retirer compl�tement la n�cessit� de passer $db � ces m�thodes.

Contraintes:
#1: J'ai besoin d'acc�der � 2 bases de donn�es : pas de singleton (� priori).
#2: J'aimerais utiliser une bonne pratique, et pas une solution tordue.
#3: Je pense �ventuellement � impl�menter PDO. La solution ne devra pas poser de probl�me d'�volution � ce niveau.


Mes solutions:

#1:
Passer par r�f�rence $db au constructeur de chaque objet qui pourrait en avoir besoin. Les objet stockeraient $db. (toujours par r�f�rence). Les m�thodes pourrait donc faire $this->db->query(....);

Avantage: Je n'ai plus � passer $db dans les param�tres de mes m�thodes d'objet
D�savantage: Je dois encore passer $db � mes actions (statique), car parfois l'action instancie de nouveau personnages, ou des objets d'usage syst�me.

#2:
global $db;

Avantage: Cool, il est partout
D�savantage: Contrainte #2: Il me semble que ce n'est pas une bonne pratique.

#3:
Cr�er une classe singleton qui g�re des instances de $db.
Son usage ressemblerait �:

Code : S�lectionner tout - Visualiser dans une fen�tre � part
1
2
3
4
5
6
7
8
9
 
//Dans ma page index.php:
$dbs = new DbSingleton();
$dbs->newDb('connexion1', HOST, BASE, USER, PASS); //Créer une classe $db, contenu dans un array du singleton ( $this->arrDb['connexion1'] = new MySQLdb(...); )
 
//Dans une méthode quelconque:
$dbs = new DbSingleton(); //Retourne l'instance du singleton existant
$db = $dbs->getConnexion('connexion1'); //Retourne l'objet $db par référence
$db->query(...);

Avantage: Cool, il est partout (enfin je crois, j'ai pas souvent utilis� de singleton)
D�savantage: Contrainte #2: Ca me semble tordu.


Bon, je doute d'avoir r�ussit � �tre clair, alors si vous avez des questions, n'h�sitez pas. Et je sais que je ne dois pas �tre le premier � avoir fait face � ce probl�me, peut-�tre pourrez-vous m'�clairer sur la meilleure approche ?