Zend FR

shiryu a écrit:

Dans la classe User se trouve aussi toute la logique métier (par exemple les méthodes login(), logout()).

Bien chez moi ces fonctions sont dans le controlleur. Ma classe Row est pratiquement vide

shiryu a écrit:

UserGateway contient par contre toutes les méthodes ORM (findByEmail(), findByPays(), etc.)

Pareil pour moi, sauf que j'ai intégré le design pattern façade. Ainsi, j'ai un seul point d'entrée pour appeller toutes les fonctions du modèle

shiryu a écrit:

PROBLEME :

Retourner automatiquement une instance User avec les propriétés de l'objet, c'est sympa car on a aussi accès immédiatement à toutes les méthodes de l'objet, mais que faire si on a juste besoin de récupérer l'email certaines fois sans avoir besoin des méthodes de l'objet ?

J'utilise la fonction toArray() dans mes rows pour récupérer uniquement les champs.

shiryu a écrit:

J'ai aussi l'impression d'avoir à écrire une méthode par requête ce qui me fait perdre beaucoup de temps. Est-il bon d'écrire la requête SQL dans User et de simplement faire appel à UserGateway()->query() pour exécuter la requete ? Ou alors toutes les requêtes doivent être dans UserGateway, et on y accède via des méthodes publiques ?

Chez moi c'est le cas, toutes les requètes dans table.

shiryu a écrit:

Ensuite comment classer une méthode qui fait appel à des données de 2 tables 'users' et 'comments' ? On placera la méthode dans UserGateway ou dans CommentGateway ?

Ben, à mon avis ça dépend de quel controlleur tu appelle cette méthode. J'ai écris certaines méthodes de ce genre dans mon modèle, je les ai mis dans le modèle "principal" du controlleur concerné (dans user_Table pour UserController par exemple).

Voici mon arborescence :
   -->Model
        -->User
             -->Form
                 -->Default.php
                 -->Login.php
             -->Table.php
             -->Row.php
        -->User.php (Composant de la façade)

J'ai mis en ligne un squelette d'application (crud).
Tu peux peut-etre t'en inspirer...

Cordialement,
Lesauf

Hum, le fait est que Zend_Db récupère lui-même les noms des champs de la bd. Ainsi, (à moins de changer le nom de la table) tu n'a pas à "corriger plusieurs classes chaque fois que j'ajoute une colonne dans une table".

Peut-etre que si tu jetais un oeil à mon squelette d'application tu comprendrais un peu mieux.

L'idée c'est justement de ne pas gérer la chose soit-même (c'est pour ça qu'on utilise un framework).

A plus,
Lesauf

Dernière modification par lesauf (18-06-2009 09:10:49)

J'ai le même problème avec le Zend Framework que toi Shiryu. J'ai fait un autre post sur le forum qui rejoint celui-ci : http://www.z-f.fr/forum/viewtopic.php?id=3401

J'ai regardé Propel et Doctrine, Doctrine a apparemment déjà été intégré au ZF avec succès, et permet d'avoir un solution ActiveRecord à l'ORM dans le Zend Framework. Mais Doctrine l'avoue lui même, ActiveRecord est pas idéal, et Domain Model (ou Domain-Driven Design) serait mieux.

Et justement, je redonne les liens vers deux blogs en anglais qui donnent des pistes intéressantes pour faire du Domain Model ave ZF :
Celui que je préfère, proche du quickstart de ZF 1.8 avec le pattern Mapper : http://www.angryobjects.com/2009/03/30/ … framework/,
Et le second, avec le pattern Gateway : http://weierophinney.net/matthew/archiv … cture.html.

J'espère que ça pourra aider !

@lesauf
Désolé pour la confusion 1-1, c'est moi qui ai induit une incompréhension inutile. J'ai corrigé mon post, je voulais parler du principe créer une classe pour un table de la base de données. Chaque classe accède à sa table, c'est le modèle proposé par Zend Framework dans la doc (au jour d'aujourd'hui du moins !). Dans la pratique, on a vite besoin qu'une classe puisse accéder aux données de plusieurs tables sans avoir à créer des vue systématiquement dans la table.

Le mapper est une classe intermédiaire entre une classe et la base de données. Le verbe "mapper" signifie faire correspondre les données d'une structure avec une les données d'une autre structure. L'idée du mapper est de rendre totalement indépendantes les classes métiers et la base de données. La classe ne doit pas connaître la BDD et la BDD ne doit pas connaître la classe. Si elles veulent communiquer elles doivent passer par le mapper. Dans le quickstart, ce n'est pas un vrai mapper car ils proposent $user->save(). C'est à dire encore une fois que la classe métier sauvegarde (donc sait qu'une base de données existe !!, ce qui rend l'intérêt d'un mapper nul).

Dans une vraie conception du mapper, c'est comme Ramos le dit, la sauvegarde d'un objet se fait ainsi : $mapper->save($user). La méthode save s'occupe alors de décortiquer ton objet et d'enregistrer les infos à la bonne place.


@Ramos
Tu as trouvé en effet un site très intéressant. Son approche est assez différente et je vais réfléchir sur ses possiblités par rapport à mon application.

Par contre je ne comprends pas vraiment en quoi il utilise un mapper. D'après ce que j'ai compris, il structure son application en services. C'est à dire que si le controller a besoin de quelque chose, il fait appel à un service. Ce service s'occupe de charger les objets nécessaires et les données des objets pour créer un résultat qui est renvoyé. Dans ce schéma les classes métiers et la base de données sont bien séparées.

Ce qui est sympa, c'est qu'il crée des classes spécifiques pour chaque table qui permet d'accéder aux données, MAIS sans jamais générer des objets métiers à partir de ces données, et c'est bien là que la doc de Zend Framework mélange un peu tout. Un Zend_Db_Row n'est pas égal à une classe ! Un Zend_Db_Row est comme son non l'indique une ligne dans une table. Le modèle proposé permet donc d'utiliser un service pour enregistrer ou récupérer les données à partir de n'importe quelle table (on utilisera les classes dérivées de Zend_Db_Table pour récupérer des données d'une table, ou au besoin Zend_Db_Table_Select si les requêtes sont plus spécifiques (jointures et autres joies de l'informatique !). Si c'est une sélection sur une table, elle renverra un Zend_Db_Table_Row par exemple, c'est le service qui le récupère et l'exploite pour alimenter mon objet ; le service poursuit toutes ses opérations pour créer le résultat qu'on lui demande et le renvoie.

Le principe est très proche du mapper, mais un service peut mélanger toutes sortes de choses : la gestion des logs, du cache, de la BD, du filtrage, etc. Le mapper est spécifique à la gestion de la base de données uniquement.

C'est très intéressant car le service permet justement de gérer plusieurs choses à un endroit stratégique de l'application ET surtout il permet de faire évoluer l'application vers d'autres supports (téléphones portables, etc.) treès facilement.

Un GRAND merci à toi pour ce lien, je vais regarder un peu plus ce design pattern pour trouver une vraie solution (celle de Zend est un peu décevante je trouve et fausse certaines bonnes pratiques).

Moi aussi je travaille avec une façade découpée en composants. Mais si j'ai bien compris (je n'ai pas encore pris le temps de faire de recherches), le mapper est entre le modele et la bd.

Ainsi on aurait :
Controlleur -> façade -> modele -> Mapper -> BD.

J'ai bien compris?

D'après ce que je lis dans le Quickstart, les deux patterns (façade et mapper) ont le même but et sont complémentaires. Leur implémentation diffère un peu.

Dans le pattern façade, les modèles sont directement invoqués et les requêtes directement traduites pour ces modèles.

Dans la conception que je vois dans le Quickstart, Default_Model_Guestbook porte la logique métier, et ensuite derrière, le mapper est équivalent à une façade et connait l'organisation de la base de données et les classes qui correspondent.

Donc de même qu'avec le pattern façade, si la techno pour la persistance change, seul le mapper est ré-écrit (avec les classes de la persistance biensur). Le métier ne change pas et les controlleurs eux ne sont jamais touchés.

Je dirais que c'est donc le mapper qui va porter les méthodes censées retourner des données de plusieurs tables. Il invoquera toutes les collections de données nécessaires pour répondre à la demande métier.

C'est donc à lui de savoir quelles sont les classes à charger et les méthodes à invoquer dans les modèles.
Donc attention, le mapper n'est pas lié à une table, c'est simplement une interface entre le métier et la persistance.

En ce qui concerne la répétition de code, parfois c'est inévitable.
Il faut surtout comprendre que les setters et les getters sont écrit pour le métier et non pour les modèles.
Si je veux récupérer un commentaire, je dois implémenter une méthode getComment(), peu importe la façon dont sont organisées les données, c'est au mapper de se démmerder avec ça. S'il doit invoquer plusieurs modèles ou faire appel à une méthode qui récupère des données sur plusieurs tables jointes, celà ne concerne ni le métier ni le controlleur. Pour le controlleur, getComment() renvoie un commentaire, pas besoin d'en savoir plus.

En tout cas, tout ça est très intéressant. Je trouve que Zend aborde le sujet un peu tard.
Pour une petite application il est certain que toute cette conception est sur-dimensionnée, mais dès que le métier est un peu plus complexe, ça prend tout son sens.

J'ai pas trop approfondie la chose, je lis la doc et le quickstart pour l'instant et je compare avec ce que j'avais implémenté de mon côté.

N'hésitez pas à m'arrêter si vous pensez que je me trompe, que je n'induise personne en erreur


A+ benjamin.

Dernière modification par Delprog (19-06-2009 13:48:43)

Je suis d'accord avec ce schéma qui place très bien le mapper et une façade à leur place :

Controlleur -> façade -> modele -> Mapper -> BD

La Façade est un design pattern qui ne devrait faire appel qu'à des méthodes du modèle. Elle sert à faciliter l'utilisation du modèle. Par exemple, j'ai 4 télécommandes pour gérer ma télé, mon ampli, canalsat, mon magnétoscope. Si je veux enregistrer TF1, je dois allumer chacun de ces appareils, mettre canalsat sur TF1 et exécuter le mode enregistrement de mon magnétoscope. Très compliqué notre modèle métier pour une personne qui connaît pas. Pour ma grand-mère qui veut enregistrer les feux de l'amour mais ne pige rien à tous ces appareils, je lui crée une télécommande spéciale (la façade). Elle appuie sur un bouton, et toutes les opérations nécessaires sont exécutées automatiquement. La façade n'a aucun rapport avec la base de données. Dans les gros projets elle sert souvent aux équipes pour leur faciliter l'utilisation du modèle, comme ça ils peuvent développer sans avoir à tout comprendre de la complexité du modèle. Ainsi plusieurs équipes peuvent travailler sur un même projet mais sur des parties différentes.

En revanche le Mapper sert exclusivement à faire correspondre la structure d'une classe avec la structure d'une ou plusieurs tables dans la base de données. Le Mapper est une approche de la gestion des données. La Façade est une facilitation du modèle.

Dernière modification par shiryu (19-06-2009 16:39:15)

Exactement,

Donc la façade n'a pas d'intérêt ici je dirais.

Et le schéma serait plutôt,

Controlleur -> classe métier -> Mapper -> modèle

Dans le Quickstart:

Controlleur -> Default_Model_Guestbook -> Default_Model_GuestbookMapper -> Db_Table

Default_Model_Guestbook : porte la logique métier
Default_Model_GuestbookMapper : transforme les requêtes pour les Db_Table
Db_Table : persistance.

De la même manière qu'une Façade le Mappeur peut-être une coquille vide, on peut donc mettre un bouchon, avancer sur le dev de l'application sans encore avoir implémenté la couche qui gère la persistance.

Pour moi ce sont deux conceptions, et dans ce cas, je ne vois pas l'intérêt d'utiliser et une Façade et le Mapper.
La classe métier pluggée à un Mapper suffisent.

Mais je planche encore dessus, peut-être que quelquechose m'échappe.


A+ benjamin.

oui je comprends pourquoi tu vois le mapper dans ce schéma :

Contrôleur -> Mapper -> BDD (Zend_Db)

Cela dépend si on le voit d'un point de opérationnel ou fonctionnel.

Dans la façon opérationnelle (sa mise en oeuvre) :
on l'instancie dans le Contrôleur et on exécute ses méthodes qui gère nos données. Par exemple dans le contrôleur :

// mon objet métier
$u = new User();
$u->setNom('toto');
$u->setPrenom('tata');

// mon mappeur pour gérer les données de l'objet métier User
$m = new $mapperUser();
// enregistre mon objet métier en base de données
$m->save($u);

// je veux charger un User à partir de son email
// le mappeur va charger toutes les données de l'objet s'il trouve un résultat
$u2 = $mapper->findByEmail('titi@exemple.com');

On voit que le mapper sait gérer les instances de User et sait parfaitement où se trouvent les données. Jamais on ne fait appel à une requête depuis l'objet métier. Le quickstart présente pourtant un schéma de ce genre $u->save() qui fait appel à $m->save(), ce qui est contraire aux objectifs du mapper.

Dans la façon fonctionnelle (son rôle, sa fonction) :
Comme il est joue le rôle d'adaptation des données d'une structure objet à une structure de base de données relationnellle, et inversement, on le voit alors de façon conceptuelle située entre le modèle métier et la base de données. Il s'agit d'une vision en couches, donc plus abstraite. La vision opérationnelle est une vision concrète

Dernière modification par shiryu (20-06-2009 12:03:28)

Je ne vois pas de contre-indication à ce que tu proposes, c'est tout à fait possible de le concevoir comme ça. Et rien ne t'empêche d'avoir à la fois un save() et un addUser() dans ton mapper.

Avec une méthode find() c'est particulièrement utile d'avoir à passer juste l'id unique plutôt que tout un objet :

// id unique du user
$userId = 1;

// instancie le mapper pour les users
$m = new $mapperUser();

// récupère une instance de User() à partir du mapper qui se charge de créer
// l'instance de lui effecter ses données et de retourner un resultat
$user = $m->find($userId);

Ce qu'il faut comprendre c'est que le Mapper ne doit pas encapsuler exclusivement le modèle. Tu peux parfaitement avoir une instance de User dans le controller, c'est là pour ça. Le modèle doit gérer toute la logique de l'application. Tu fais appel au Mapper juste pour gérer la persistance de tes objets de et vers la base de données.

Dernière modification par shiryu (21-06-2009 15:11:03)

ramos a écrit:

Et justement, je redonne les liens vers deux blogs en anglais qui donnent des pistes intéressantes pour faire du Domain Model ave ZF :
Celui que je préfère, proche du quickstart de ZF 1.8 avec le pattern Mapper : http://www.angryobjects.com/2009/03/30/ … framework/,
Et le second, avec le pattern Gateway : http://weierophinney.net/matthew/archiv … cture.html.

J'espère que ça pourra aider !

Deux tres bonne slectures à condition de prendre le temps de bien lire et comprendre

Moi je trouvais simple de pouvoir faire

$u = new User();
$u->setNom('toto');
$u->setPrenom('tata');
$u->save;

ou encore

$u = new User();
$u->find('2'); //pour trouver le user d'ID = 2

ou même

$u = new User();
$u->findByEmail('toto@titi.com');

Symphony semble fonctionner de cette façon. A aucun moment nous avons accès directement au mapper...