Discussion :

[comode]

Bonjour,

Voilà une question qui m'empêche régulièrement de dormir.

Admettons que j'ai un 1er objet NEWS qui comme son nom l'indique représente une news sur un site web, et un autre objet USER qui correspond à un utilisateur inscrit de ce même site web. A coté de ça, on à une base de donnée qui contient ces 2 tables et dont les champs correspondent aux attributs de ces 2 class (cas très classique en somme) :

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
32
33
34
35
36
class news
{
   public $id;
   public $titre;
   public $texte;
   public $redacteur; // en BDD, contient l'ID d'un user
 
   public function GetRedacteur() {} // retourne un objet de type user
}
 
class user
{
    public $id;
    public $nom;
    public $prenom;
}
 
// et comme on est civilisé, on va utiliser des managers pour gérer la persistance
 
class ManagerNews
{
   private $bdd;
   public function add(news $n) {...}
   public function upd(news $n) {...}
   public function del(news $n) {...}
   public function get($id) {...}
}
 
class ManagerUser
{
   private $bdd;
   public function add(user $u) {...}
   public function upd(user $u) {...}
   public function del(user $u) {...}
   public function get($id) {...}
}

On fait abstraction des setters et getters qui ne sont pas utiles pour la question.

Imaginons maintenant que je veuille instancier une NEWS à partir d'un enregistrement de la base de données :

Code :

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

1
2
$mn = new ManagerNews();
$MyNews = $mn->Get(10);

La question est donc de savoir que faut-il stocker dans l'attribut news::redacteur, et donc indirectement que doivent faire les fonctions news::getRedacteur() et surtout managerUser::get(), car je vois au moins 2 façons distinctes de faire, toutes 2 lourdes d'inconvénients...

1) On peut stocker un objet de type USER, auquel cas, il faudra le créer en même temps que l'instance de news. Du coup, news::user() retournera juste cet attribut brut de décoffrage. Par contre, je trouve cette solution très inquiétante pour les perfs de l'appli, surtout si user contient a son tour des objets.

2) on peut stocker l'ID (integer) du user qui à rédigé la news, et chaque appel à news::getRedacteur() entrainera la création d'un managerUser et un appel BDD pour créer $redacteur...

J'avais opté dans un précédent projet pour un système de cache, ou on stock l'id à la création de l'objet et un attributs de cache vide. A chaque appel de getRedacteur(), on test alors si il y a quelque chose dans la variable de cache, on instancie l'objet et on la met dans le cache si c'est pas le cas, puis on retourne le cache. Cette solution combine à priori les avantage des 2 méthodes sans les inconvénients, sinon de perdre un peu le contrôle sur la consommation mémoire de l'appli, mais elle me laisse une impression de sale et j'ai l'impression de passer à coté de quelque chose...

Aussi à votre avis, quelle est la meilleure façon de faire ?

[rawsrc]

Salut,

c'est une très grosse problématique récurrente.
Je ne vais rien t'apprendre mais sache qu'il n'y a pas de solution universelle.

Sur des applis complexes où il y a pléthore d'instances imbriquées, interdépendantes il faut chercher l'équilibre entre performance, fonctionnalités et architecture. Et ben c'est loin d'être simple.
C'est une des limitations forte du PHP. Là où d'autres langages ont accès à des serveurs d'applications qui optimisent nativement ces aspects, PHP n'en a pas et de par son fonctionnement stateless, il faut recourir à des bidouilles pour ne pas être trop pénalisé : le cache en est une qui donne de bons résultats.

Pour limiter le goulot d'étranglement qu'est l'accès à la base de données, il y aussi une autre approche s'inspirant des bases de données "épaisses", tu créés des vues larges ; dans ton cas, une vue qui rapatrie en même temps les données de l'article et celle du rédacteur. Ne reste plus ensuite qu'à hydrater tes objets à partir de ce résultat.

Il est de très loin préférable en terme de performance de rapatrier de la base de données un résultat plus conséquent que de faire pleins d'appels successifs.
La contrepartie (y en a toujours une), c'est que cela t'oblige en amont à concevoir intelligemment les vues répondant aux différents besoins de ton application.

Avec les performances actuelles des moteurs de SGBDR, c'est à mon avis une très bonne approche. Tu bénéficies ainsi de données à jour et d'excellentes performances.

[Spartacusply]

Rawsrc a tout dit.

Ce qui me semble important c'est que l'on puisse régler ce niveau de récursivité d'une manière ou d'une autre, c'est à dire pouvoir définir jusqu'à quelle niveau de relation dans la base de données récupère t-on les informations.

Par défaut, dans une logique de CRUD, il me semble cohérent de placer ce niveau de récursivité à 1 : c'est à dire je récupère les informations de l'user et des classes qui lui sont liées (en l'occurence les news), mais si ces news sont liées à d'autres informations (des commentaires par exemple), je ne récupère pas ceux-ci (et n'y est donc pas accès si je ne fais rien dans mon php).

Après, il faut vraiment faire en fonction du type de site, de la construction de la bdd et des complexités des relations. Si dans une vue particulière on ne récupère que les informations de la classe elle-même, plus une information se situant à 4 ou 5 relations, il vaut mieux privilégier une seule requête spécifique qui ira chercher cette information plutôt que tout ramener au passage.

[comode]

Merci pour ces réponses qui auront au moins le mérite de me rassurer quant au fait que je ne passe forcément à coté de quelque chose de majeur depuis plusieurs années