Discussion :

[Jukien]

Salut,

Je pose le problème ici car je développe en PHP, mais il concerne plus particulièrement la manière d'aborder le problème. Le concept, donc.

Pour expliquer mon propos simplement, je propose de prendre un exemple simple. imaginons que je dispose d'une table contenant des articles, et deux classes pour les gérer correctement.

Je vais au plus simple, je passe certains constructeurs, certaines vérifications de données, ainsi que la définition de certaines méthodes.

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
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
class Catalogue
{
 
protected $db;
 
public function creerArticle() { }
 
public function getArticlesByUser($username)
{
 
   $articles = array();
 
   $this->db->query('SELECT article_id, ... FROM article WHERE username = ...');
 
   while ( $d = $db->fetch_assoc() )
   {
      $articles[] = new Article($d);
   }
 
   return $articles;
 
}
 
 
public function getArticlesByCategorie($username) { }
 
... 
 
}
 
 
class Article()
{
 
protected $id;
protected $name;
...
 
function __construct($mixed)
{
   if ( is_int($mixed) )
   {
      $this->db->query('SELECT article_id, ... FROM article WHERE id= ...');
      $mixed = $db->fetch_assoc()
   }
   $this->id = $mixed['article_id'];
   $this->name = $mixed['article_name'];
}
 
public function supprimer() { }
 
public function getName() { }
 
...
 
}

En gros, c'est le principe, avec des contrôles sur l'intégrité des données en plus.


Le problème... Dans un soucis d'économiser les requetes SQL au nécessaire (et donc de ne pas charger tous les articles), le code devient vite crade, et ne respecte pas forcement les concepts de la POO. Du moins, la class Catalogue pourrait être static, ça ne changerait rien, et les arguments ne sont pas passés proprement à la class Article. Cependant, laisser la classe Article faire une requete SQL pour charger les données chaque article n'est pas envisageable !

Autre soucis, au niveau de la redondance SQL. Rien ne m'empeche de charger plusieurs fois un même objet (par exemple, si je fais un new Article(6) suivit d'un second new Article(6), 2 requetes SQL seront créées). de même si je fais un new Article(8) alors que cet article a déjà été chargé lors de l'appel de getArticlesByUser('toto') par exemple.

J'avais imaginé détourner le principe du sigleton (par exemple, un tableau static contenant plusieurs instances, selon l'ID de l'article), mais ça s'éloigne beaucoup trop du concept de la POO.

Bref, si vous avez des conseils sur l'architecture à adopter, ou même des mots clés à me donner pour faciliter mes recherches Google, ça m'aiderait beaucoup.

Merci d'avance.

[Jukien]

Pour remonter ce vieux topic resté sans réponses, voila la technique adoptée :

La classe Catalogue est toujours utilisée pour récupérer un article (par son id, son auteur, ou tout autre variable).*Elle hérite d'une class DBCache, qui lui permet de stocker les objets chargés en mémoire.*Ainsi, si on lui demande à nouveau l'article 81, elle n'ira pas le charger à nouveau depuis la DB.

Ensuite, la classe Article hérite d'une class CRUD, qui gère tous les accès DB (update, create, delete...). Les informations sur la structure de données (table, champs) sont stockées au niveau de la table Article.

Pour le moment, ce modèle fait ses preuve : c'est léger, le nombre de requêtes est assez optimisé, et le développement très agréable. Qu'en pensez-vous ?*Des suggestions pour améliorer cela ? Ou des retours d'expérience ? Vous faites comment vous ?

Note : j'ai aussi tenté de passer par un pattern ActiveRecord, sans succès. Ca marchait, mais je n'ai pas aimé.

[0coco0]

Salut

Ben, d'apres ton dernier postes, je pense que tu t'est approcher de la solution adequate de ton problem. Je veux juste ajouter quelques propositions, ceci peut ne pas etre la solution optimal mais ca marche bien.
Ton application doit etre separer en differentes couches, chaque couche ayant une fonction specifique. La maniere dont j'organise mes couche et la suivante:

• Model
• DAO
• Service
• Controller

+Le Model va contenir les classes metiers. Dans ton cas, ca sera Catalogue et Article.
+La couche DAO pour (Data Acess Layer) est la couche responsable de la persistance de tes objets metiers. On pourra donc avoir deux classe CatalogueDao et ArticleDao. Chaque classe contiendra des CRUD pour les objets qu'elle manipule. Cependant, j'ai commencer a travailler avec un outil de MOR nommee Doctine. C'est un outil tres puissant... En effet je n'ai donc plus qu'a creer une seule classe CatalogueDAO pour gerer le catalogue ainsi que les qrticle. Par exemple pour ajouter un Catalogue avec tout les articles qu'il contien je vais appeler une methode ajouter($catalogue) qui fera tout le boulot pour moi.
+La couche Service et une couche intermediaire entre les controlleur et la couche DAO. Ici, je joue avec mes classe objet et mes Dao pour produire les operations specifique.
+Finalement, je n'aborderai pas le controlleur car c'est assez trivial.

Bon courage pour la suite