Discussion :

[comode]

Bonjour,

Voilà, je voudrais entamer une discussion sur la meilleure façon d'utiliser le SQL dans un projet en programmation orienté objet. Je ne parle pas de la PDO ni de singleton ou autres design pattern, mais plutôt de savoir quand utiliser une requête SQL.

Je m'explique... La plupart du temps, j'ai des tables qui sont très proches des objets définis dans le code. Par exemple, qui n'a pas déjà eu un cas avec une table client et un objet CClient... On est bien d'accord qu'une bonne parties des méthodes de CClient permettrons de lire ou écrire dans la table client ? on aura surement les méthodes get/set pour chaque champs non fonctionnels de la table.

Je vois 2 philosophies pour gérer ce types de cas de figure en POO... Soit on tape dans la base via une requête à chaque appel de fonction set/get, soit on fait une class qui lit toutes les données du client dans le constructeur, qui stock ces données sous formes de paramètres, et qui travail autant que possible sur ces données directement stocké dans la class.

Mais perso, je trouve les 2 cas affreusement mal foutus par rapport a ce qu'on aurait en programmation procédurale. Soit on pioche ce dont on a besoin au travers d'une multitude de requêtes (ce qui me parait très peu performant), soit on minimise le nombre de requêtes, mais on fait péter la mémoire. Qui plus est, même en faisant une seule requête globale dans le constructeur de la class, à chaque instanciation d'objets, on doit re-préparer la requête, sauf à gérer un système de cache (vous allez me dire que le cache est déjà pal mal géré par la PDO/sql, mais on reste tributaire de la configuration du serveur).

Bref, si vous voulez afficher un listing du nom de tous vos clients, ce qui en procédurale est une opération ultra light devient un truc monstrueux en interne si on programme en pur orienté objet.

Aussi j'aimerai savoir quelle est votre approche face à ce problème ? Voyez vous d'autre façon d'attaquer la base de données en POO ?

En vous remerciant

[Seb33300]

La 2eme solution est probablement la meilleure.

Dans la mesure ou ta requête ne doit remonter qu'une seule ligne à chaque fois, même si tu dois récupérer tous les champs de la table, ce ne sera que pour une ligne, donc tu ne vas pas non plus saturer ta mémoire.

Après, ça reste effectivement très primitif et il reste effectivement quelques problèmes.
Si tu dois par exemple aller cherche plusieurs lignes dans ta base, tu va te retrouver à faire autant de requête que de lignes à récupérer.
Et pour pallier à ça, il faut rentrer dans des architectures d'objets un peu plus complexes.
Ou même tout simplement faire une requête qui va récupérer toutes tes données. Boucler sur les résultats, instancier des objets "vides" et les peupler un par un manuellement.

Après, le plus simple reste tout de même l'utilisation d'un framework comme symfony ou zend qui eux savent très bien gérer ces problématiques.

En symfony par exemple, une classe Entité va correspondre à une table de ta base de données.
Chaque propriété de ton entité désigne une champ de ta base.
Et c'est plutôt bien fichu puisque l'on peut par la même occasion indiquer pour chaque propriété, quel est le type de champ, indiquer quels sont les champs qui font parti de la clé primaire, indiquer les contraintes d’unicités, et même les clés étagères !!

L'EnityManager de symfony comme sont nom l'indique va se charger de toute la gestion des entités.
Ainsi on va pouvoir par exemple lui demander d'aller récupérer un certain nombre de ligne dans la base, il va se débrouiller pour ne faire qu'une seule requête et te retourner toutes les entités en une seule fois.
Il a même la possibilité de faire automatiquement les jointure dans la requête pour récupérer par la même occasion les entités lié à ta premières entité (clés étrangères que tu aura défini au niveau des propriétés)

[grunk]

Ainsi on va pouvoir par exemple lui demander d'aller récupérer un certain nombre de ligne dans la base, il va se débrouiller pour ne faire qu'une seule requête et te retourner toutes les entités en une seule fois.

Est ce que tu peux dire à symfony retourne moi la liste de toutes les entité mais juste avec le champs id et login (par exemple) ? Et donc obtenir des objet partiellement rempli , bien plus léger que les objets complets.
Ca semble être ça sa problématique.

Perso , je suis plus pour écrire les requête SQL à la main et surtout éviter tout ORM. J'aime avoir le contrôle complet sur ce que je demande au serveur SQL et sur ce qu'il me répond. Evidemment c'est moins facile et plus long qu'utiliser les méthodes toute prêtes des ORM. Ceci dit c'est un choix très personnel.

Pour être plus précis sur ma façon de faire:

Si ma requête retourne toutes les informations d'un objet et que je suis suceptible de devoir le modifier , la méthode de mon modèle va me retourner un objet.
Au contraire si ma requête est plus destinée à récupérer un jeu de données précis et ne se destine qu'à l'affichage je vais retourner un tableau.

Un petit exemple pour illuster :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
class User
{
   private $nom
   private $prenom
   private $id;
}
 
class UserModel
{
    public function add(User $user)
	{
	    $p = $pdo->prepare('INSERT INO ...');
		$p->execute(array(':nom' => $user->nom, ':prenom'=>$user->prenom));
	}
 
	public function getById($id)
	{
		$user = new User();
		$pdo->prepare('SELECT nom,prenom,id FROM users WHERE id = :id');
 
		//Remplissage de l'objet user
 
		return $user //Retour d'un objet
	}
 
	public function getNameAndIdList()
	{
		$pdo->prepare('SELECT nom,id FROM users');
		return $pdo->fetchAll(); //Retour d'un tableau
	}
}

Mais dans tous les cas je préfère avoir des méthodes spécialisée qui vont retournée exactement ce que je veux.