Discussion :

[Lystik]

Bonjour à tous !

Actuellement en train de travailler sur un projet pour parfaire mes connaissances sur Php Objet, j'ai quelques questions à vous poser.

Pour ce projet j'utilise quelques design pattern minutieusement choisis et adaptés à celui-ci. Bien que mon projet ne soit pas énorme et donc que l'utilisation de un ou deux DP soit un peu démesurée, je le fais surtout pour m'améliorer : le projet étant dans une optique de travail.
De ce côté là je pense que mon architecture tient la route.

Pour mes questions je vais plutôt partir sur un exemple très simpliste.
Cependant, j'ai quelques doutes sur tout ce qui concerne les échanges avec la base de données.
Actuellement, je travaille en MVC. Du côté Model, j'ai l'arborescence de dossiers suivante :

- Model

• Interface
  
  • artiste.int.php
• Classe
  
  • artiste.class.php
• Manager
  
  • artiste.manager.php
  • manager.manager.php
• Exception

Voici le code du fichier manager.manager.php

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
<?php
	class Manager{
		protected $_db;
 
        public function __construct($db)
        {
            $this->setDb($db);
        }
 
		public function setDb(PDO $db)
        {
            $this->_db = $db;
        }
	}
?>

Voici le code du fichier artiste.int.php

Code :

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

1
2
3
4
5
6
<?php
	interface IArtiste{  
		public function getPrenom($prenom);  
		public function getNom($nom); 
	} 
?>

Voici le code du fichier $artiste.class.php

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
<?php
	class Artiste implements IArtiste{
        private $_prenom;
        private $_nom;
 
		public function getPrenom(){
			return $this->_prenom;
		}
 
		public function getNom(){
			return $this->_nom;
		}
 
        public function __toString(){
            return $this->_prenom.' '.$this->_nom;
        }
	}
?>

Voici ce que fait mon manager :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
13
<?php
	class ArtisteManager extends Manager {
        public function getInfosProfilInterprete($id){
            $q = $this->_db->prepare('SELECT * FROM ARTISTE WHERE ID_ARTISTE = :id AND TYPE_ARTISTE = INT');
            $q->bindValue(':id', $id);
            $q->execute();
            $res = $q->fetch(PDO::FETCH_ASSOC);
            $art = new Artiste($res['PRENOM_ARTISTE'],$res['NOM_ARTISTE']);
            return $art;
        }
	}
...
?>

Venons en à mes questions à présent.
Déjà est-ce que cette structure est plutôt correcte niveau implémentation objet ?
Et sur mon projet, on trouve dans chaque manager la totalité des fonctions qui sont chargées d'aller "piocher" les données dans la DB et qui me fabriquent mes objets.
Cependant, on imagine bien que le manager Artiste va comprendre une grande quantité de fonctions diverses. Bien que ces fonctions ne concernent que la table Artiste, je trouve tout de même que mon manager devient vite bordélique. Je pense alors que je loupe quelque chose d'évident dans la conception de mon projet. Comment pourrais-je rendre plus lisible la lecture de mes managers ?

Merci d'avance pour votre réponse, je me tiens à votre disposition si vous souhaitez de plus amples informations.
Cordialement,
Lystik.

[ovh]

Plutôt que d'essayer de réinventer la roue, je ne saurais que te conseiller de passer par des technos modernes et éprouvées, qui te guideront dans les bonnes pratiques de dev : le framework Symfony 2 et l'ORM Doctrine 2. Tu verras, tu t'y retrouveras très bien
Ces 2 libs ont été complètement refondues dans leur version 2 pour justement intégrer les meilleures pratiques et patterns orientés objet en PHP.

Ceci dit, ton archi est bonne : les classes entités (artiste) doivent ignorer la persistance, que tu gères via un service externe (manager). C'est le pattern data mapper utilisé par Doctrine 2, et opposé à la plupart des ORM qui utilisent plutôt un pattern de type active record ou table data gateway (où les entités étendent une classe de base pour accéder à des méthodes de requêtage de la base).
Tu es donc sur la bonne voie Continue à penser en terme de découplage (principes SOLID), archi orientée service (SOA), et passe à Symfony2 tu verras tu ne seras pas déçu

Un peu de lecture :
http://www.phptherightway.com/
http://www.12factor.net/

[Lystik]

Merci pour ta réponse rapide et instructive.
Je me penche dès à présent sur les liens que tu m'as envoyé et sur la prise en main du framework Symfony 2 et de l'ORM Doctrine 2.

Il est vrai qu'on me disait souvent que je n'étais pas "normal dans ma tête" pour coder du php objet sur Notepad++, mais bon j'y étais habitué... jusqu'à maintenant ! A présent, l'architecture logicielle de chaque projet que j'entreprends devient un peu trop complexe et je passe plus de temps à me dire : est-ce que je structure bien mon projet ou pas ?

En tout cas, merci et je reviendrais vous donner des nouvelles !

[comode]

Bonjour,

Ceci dit, ton archi est bonne : les classes entités (artiste) doivent ignorer la persistance, que tu gères via un service externe (manager). C'est le pattern data mapper utilisé par Doctrine 2, et opposé à la plupart des ORM qui utilisent plutôt un pattern de type active record ou table data gateway (où les entités étendent une classe de base pour accéder à des méthodes de requêtage de la base).
Tu es donc sur la bonne voie Continue à penser en terme de découplage (principes SOLID), archi orientée service (SOA), et passe à Symfony2 tu verras tu ne seras pas déçu

Serait-il possible de nous en dire un peu plus (et en quelques mots) sur ce data mapper pattern ?
Perso, je suis habituellement plutôt Active Records, mais plus par ignorance que par choix. Qu'apporte donc réellement cette façon de faire par rapport à l'AR ?

[Nightfall]

Il y a un problème dans les propriétés de ta classe Artiste : les getters n'ont pas besoin d'argument et par contre il te manque les setters. Ce serait plutôt :

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
 
<?php
class Artiste implements IArtiste{
    private $_prenom;
    private $_nom;
 
    public function getPrenom(){
        return $this->_prenom;
    }
 
   public function setPrenom($prenom){
        $this->_prenom = $prenom;
   }
 
    public function getNom(){
        return $this->_nom;
    }
 
    public function setNom($nom){
        $this->_nom = $nom;
    }
    public function __toString(){
        return $this->_prenom.' '.$this->_nom;
    }
}
?>

Je te conseille aussi les méthodes magiques __get() et __set() qui te permettront d'écrire des choses comme :

Code :

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

1
2
$un_artiste->nom = 'Aznavour';
echo $un_artiste->nom;

Ensuite je ne vois pas comment ton interface IArtiste va te servir, parce que si ta classe Artiste représente un objet purement métier, tu devrais en avoir qu'une version a priori.

Je te conseille de regarder comment sont faits les frameworks pour t'en inspirer.

Par exemple, pour l'active record en php :
http://www.phpactiverecord.org/
https://github.com/kla/php-activerecord

Continue d'apprendre, c'est bien parti

[Lystik]

Oula oui ! C'est une bête erreur d'étourderie de ma part (je suis allé vite quand j'ai tapé le message, sûrement trop car j'ai fait un mix des get/set. Pas de problèmes côté ascesseurs !

J'ai mis un exemple très simplifié pour illustrer et savoir si l'architecture était bien construite, donc il est vrai que l'interface ici n'est pas nécessaire ! Mais dans un cas concret je gère des produits, pour lesquels j'ai besoin de cette architecture !

[ovh]

Serait-il possible de nous en dire un peu plus (et en quelques mots) sur ce data mapper pattern ?
Perso, je suis habituellement plutôt Active Records, mais plus par ignorance que par choix. Qu'apporte donc réellement cette façon de faire par rapport à l'AR ?

Voici une réponse que j'avais apportée à cette question il y a quelques temps
http://www.developpez.net/forums/d12...p/#post6994541

[comode]

Hélas, les 3 liens que tu donnais à l'époque pour expliquer pourquoi il y a des vrai morceaux de Satan dans l'architecture AR sont morts :/

[ovh]

En effet dis donc, je ne sais pas ce qui s'est passé sur le forum là

Voilà un lien que j'ai pu retrouver :
http://misko.hevery.com/2009/05/05/t...active-record/

Sinon, en résumé le problème de tous les patterns genre active record, c'est le couplage fort entre les entités métier et la persistance, ce qui viole le premier principe SOLID (single responsability).
Normalement les entités doivent être des classes qui doivent pouvoir se manipuler indépendamment de leur persistance (que ce soit une base de données, des fichiers xml, json ou autre... ).
Avec un ORM comme Doctrine 2, il est conseillé d'avoir une archi de ce genre :
- entités indépendantes (ne doivent pas hériter d'une classe de base pour fonctionner)
- classes repositories pour l'interaction avec la base (équivalent des classes de type "table" dans d'autres outils)
- classe "entity manager" qui orchestre le tout
- classes de service pour effectuer les opérations en parlant aux entités, aux repositories et à l'entity manager
- les contrôleurs ne s'adressent du coup qu'aux classes de service

Bref, essayer de s'orienter vers du DDD (domain driven design), SOA (service oriented architecture), et ce genre de choses.

Autres liens intéressants :
http://jgaskins.org/blog/2012/04/20/...active-record/
http://stackoverflow.com/questions/2...-active-record

Et enfin un article de chez nous sur les principes SOLID, en .NET mais c'est bien sûr valable dans n'importe quel langage :
http://philippe.developpez.com/articles/SOLIDdotNet/