Discussion :

[Dendrite]

Bonjour,

Je développe une espèce de serveur de requêtes.
Une base mysql (appelons-la coffre) possede au moins ces deux tables :

- une table base avec toutes les infos sur les bases susceptibles d'être requêtées (id_base,nomBase,type,login,mdp,port etc.)

- une table req avec toutes les requêtes susceptibles d'être utilisées (id_req,nomReq,sql,titre,commentaire,id_base etc)

Bien...

Je crée donc une classe ConnexionCoffre, qui se contente d'instancier l'objet PDO et de le coller dans une propriété de la classe.

Après je crée une classe ConnexionDb dont le constructeur prend en paramètres (PDO $coffre,$id_base) et qui pour l'essentiel, hydrate un objet $db à partir d'un tuple de la table base...

Jusque-là, ça marche.

Le problème survient quand je veux construire une classe requete, avec le PDO passé en paramètre (PDO $coffre,$id_req)
Quand, dans le constructeur, cette classe instancie la classe ConnexionDb, ça ne fonctionne pas et ça m'envoie un message du type "bad gateway"...
Je ne comprends pas où je me trompe (est-ce dû à PDO ou à une mauvaise conception objet ?). Je débute dans les deux...

Le code de convocation donne ceci

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
$coffre=new ConnexionCoffre();
$coffrePdo=$coffre->pdo;
 
//Cette ligne de code en commentaire fonctionne dans le fichier d'appel, j'ai vérifié.
//mais pas dans la classe Requete
//$maBase=new ConnexionDb($coffrePdo,54);
 
$maReq=new Requete($coffrePdo,986);/*C'est ici que ça coince, car la ligne précédente ne tourne pas dans la classe Requete*/

[grunk]

Comme tu le présente , ta classe ConnexionCoffre n'a pas lieu d'être.

Le but étant de rentre les classes les plus indépendante possible , on doit au maximum éviter l'instanciation d'objet à l'intérieur d'une classe (injection de dépendance).

Dans ton cas il suffirait de quelque chose comme ça (si j'ai bien compris ton besoin) :

$pdo = new PDO(...);
$requete = new Requete($pdo,986);

Avec Requete ressemblant à quelque chose comme ça :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
class Requete
{
	private $db;
 
	public function __construct($pdo,$param)
	{
		$this->db = $pdo;
	}
 
	public function foo()
	{
		$this->db->query(...);
	}
}

On peut améliorer encore un peu le découplage en passant par un setter pour définir la connexion pdo mais ça implique plein de vérification supplémentaire.

[Dendrite]

Merci de tes éclaircissements, Grunk.
Si je t'ai bien compris, les classes connexionCoffre et connexionDb sont toutes les deux inutiles ?

Du coup, poursuivant sur cette lancée, je me demande si même ma classe requete est bien utile conçue ainsi :

En effet, te paraît-il judicieux de faire une classe par client, au sens informatique :
Ainsi, j'ai deux clients : un cron qui produit des fichiers csv chaque nuit, en se connectant d'abord à coffre, il boucle sur les requetes, se connecte aux bases associées, et stocke sur le serveur 1 csv/requete.
Et un "vrai" client qui affiche sa page, et ne fait que consulter ces CSV, mais je dois gérer ce qu'il a le droit de voir en fonction de son identité.
Mais attention, ultérieurement, ce client-là pourra cliquer "rafraîchir le résultat" si ça lui chante, et donc, faire à l'échelle d'une requête ce que le cron fait...

De fait, ce que j'appelle la classe requete, c'est plutôt ce que fait le cron.

Ma question devient donc :

Puis-je faire une classe Cron et une classe Client ? Ma base produira deux vues, une vue cron et une vue client, et déjà, mes objets seront automatiquement hydratés par ces vues. Ensuite, viendraient les méthodes spécifiques de chaque client. C'est ce qui paraît le plus concret et le plus simple, non ?

C'est la première fois que j'ai une appli à concevoir de A à Z en mode objet, pardon si les questions paraissent naïves.

[grunk]

Puis-je faire une classe Cron et une classe Client ? Ma base produira deux vues, une vue cron et une vue client, et déjà, mes objets seront automatiquement hydratés par ces vues. Ensuite, viendraient les méthodes spécifiques de chaque client. C'est ce qui paraît le plus concret et le plus simple, non ?

Ca parait plus judicieux comme ça.

Dans l'idéal tu créer une classe mère "Client" qui regroupera toutes les méthodes commune à tes clients et après tu dérives cette classe pour par exemple faire une classe "Cron".

Pour la conception , il faut te dire que chaque entité peut être un objet. Pour la base de données souvent chaque table est un objet.

[Dendrite]

Bon, on va dire que ma question devient : concevoir un projet web en POO.



Voici le résultat de mes dernières réflexions :

Quels écrans PHP ?

1) écran de connexion
2) écran menu de liens spécifiques vers csv une fois connecté
3) écran résultat

Ca, ca serait bien une classe Client qui navigue et toutes les méthodes associées. Pour la petite histoire, j'ai déjà fini result.php, il gère en Dojo l'affichage d'un tableau avancé, avec filtres etc...

4) cron.php

Lance en boucle la classe Requete, classe Requete qui à partir d'une connexion à coffre et d'un ID requête, construit et stocke le fichier csv qui va bien.

5) refresh.php
est un peu à part. Convoque la classe Client, vérifie les droits et convoque la classe Requete une fois.

Ainsi, j'évite toute imbrication de classe.

j'ai bon cette fois ? Avec Deux classes, une classe Client et une classe Requete ?

[Dendrite]

Pour la conception , il faut te dire que chaque entité peut être un objet. Pour la base de données souvent chaque table est un objet.

Ca j'avais cru comprendre, et ma base est bien conçue à ce titre.
Ce que je n'avais pas compris, c'est qu'il ne faut pas faire de classe qui instancie d'autre classes...

Si tu as une classe base et une classe requete, qui nécessite une connexion à une base... ben non, tu ne peux pas mettre à l'intérieur de la classe requete

$maBase=new Base('maBase');

Ca, ça me contrarie davantage.

Donc il faut que je fasse mes objets à partir de vues, si je comprends bien.

[grunk]

Ce que je n'avais pas compris, c'est qu'il ne faut pas faire de classe qui instancie d'autre classes...

C'est pas interdit , c'est juste que c'est mieux de pas le faire afin d'éviter que tes classes soit trop fortement couplée entre elle.
Ca te permet par exemple de simplement reprendre une classe pour un autre projet sans avoir à en modifier la moitié.

Après je t'avouerais que pour ton post précédent j'ai un peu de mal à te comprendre. Ça te parais sans doute clair parce que tu as le nez dans ton projet , mais de l’extérieur ça me parle pas beaucoup

[Dendrite]

Oui, pardon, j'ai le nez dedans, et le cou aussi...
En tout cas, je te remercie de tes conseils, et je m'excuse du hors-sujet.