Zend FR

Oui mais en fait mes interrogations n'ont rien à voir avec Zend_Application, la mention de Zend_Application juste dans mon introduction 36-15malife

(Précision rajoutée dans mon premier post)

Dernière modification par OsoPardo (06-05-2009 17:43:26)

Si par exemple je prend exactement la même procédure que le quickstart, et que je souhaite avoir une fonction getActiveBook() afin de me retourner les livres actifs (valeur de type BOOL 1/0 dans la db) j'ai donc créer cette fonction dans application/models/Book.php (classe "Default_Model_Book") :

    public function getActiveBook(){
        $activeBooks = $this->getMapper()->getDbTable()->select('titre')->where('active = ?',1);
        return $this->fetchAll($activeBooks);
    }

mais ça ne fonctionne pas, est-ce le bon endroit pour ce type de fonction plutot que dans le controlller ?

Je confirme que c'est completement destabilisant, si il doit y avoir 3 fichiers pour créer un model dont l'un ne sert à faire que des getter et des setters, pourquoi en pas avoir inclu un outil de generation automatique... c'est pas que c'est difficile mais c'est quand meme bien rébarbatif et il n'y a rien de tel pour démotiver un dev que de lui imposer de faire des choses aussi répétitives que d'écrire des bouts de codes aussi répétitifs que ça?

J'ai beau chercher dans la doc, google, je trouve pas comment generer un model

J'ai essayé :

zf.bat create model toto

Ca me dit qu'il comprend pas "model"

Comment vous faites ?

Justement je voudrai m'en servir, mais je ne trouve pas comment le créer via la commande

Pour ma part le fait de créer 3 fichiers est une bonne pratique!

- 1 fichier Objet Métier
- 1 fichier de Mapping
- 1 fichier représentant la table (dbTable)

Effectivement le mapper n'a pas grand intérêt si votre objet métier ne manipule ses données que dans une seule table

Maintenant admettons que votre objet métier ne manipule pas une seule table mais plusieurs:

- 1 fichier Objet Métier
- 1 fichier de Mapping
- 2 (ou +) dbTable

Il n'existe toujours qu'un seul objet métier mais celui ci via le mapper va rechercher ses données dans plusieurs dbTable


Voilà comment j'ai interprété le nouveau quickstart! Certes plus de fichier, mais également plus de flexibilité!

Je vais essayer de trouver le temps et d'en faire un petit schema

En effet, l'explication simple de CocoRambo me fait un peu ouvrir les yeux sur l'intérêt de ces trois fichiers qui représentent la partie Model pour un objet métier. Merci :-)
Cependant, j'ai encore un peu de mal à définir ce qu'est un objet métier. Je ne vois pas vraiment à quoi peuvent correspondre les objets métier dans mes applications, où retrouver un élément tel que l'objet Guestbook du Quickstart.

Pour appuyer ce que dit CocoRambo :

Les données et les objets métiers sont deux choses distinctes.

Supposons qu'on ai une table Magasin, une table Produit, et une table Stock (relation N-N classique entre Magasin et Produit). Notre modèle de données a donc trois objets Magasin, Produit et Stock.
Le modèle métier, lui n'a que deux objets : Magasin qui contient dans un attribut "stock" un tableau de produits, et Produits.

Vous allez me dire : ok, on peut consulter les stocks d'un magasin facilement, mais consulter les magasins ayant en stock un certain produit devient long. Justement, c'est un modèle métier, donc il faut l'orienter selon le besoin de l'utilisateur. Ici on considère que le besoin c'est surtout de voir les stocks d'un magasin.

On voit donc que l'objet magasin sera construit à partir des tables Magasin, Stock, et même Produit (il faut tout obtenir d'un coup avec des jointures). Le Mapper est là pour interroger la base de la bonne façon (avec la jointure) puis construit les objets Produit et l'objet Magasin qui les contient.

Voilà un exemple d'utilisation de Mapper. Je suis d'accord que ce n'est pas forcément utile pour une petite application, mais je trouve bien que le quick start l'introduise malgré tout (ça ouvre l'esprit, j'ai beaucoup appris sur les bonne pratique justement grâce aux différents quick starts du ZF, et en creusant les concepts qu'ils proposent).

Enfin, un petit bémol : à priori Zend_Db_Table n'est pas prévu pour les requêtes avec jointures vers d'autres tables liées... je me trompe peut être mais vous pouvez regarder mon autre post à ce sujet : http://www.z-f.fr/forum/viewtopic.php?id=3401.

Voilà, j'espère que ça aide. Désolé si j'ai pas fait un petit schéma en passant, mais j'espère que c'est clair quand même !

Dernière modification par ramos (16-06-2009 10:39:22)

Malheureusement Moimeme, ça ne fait que 4 jours que je planche sur le sujet donc mon code n'est pas encore fait. D'autre part, le Zend Framework a le défaut de ne pas proposer de Mapper abstrait qui permettrait de créer facilement plein de Mapper en héritant du leur...

Bref, pour le moment, je ne peux que te conseiller de bien regarder le code du Quickstart de Zend Framework section Model and Database.

Pour information, j'essaye en ce moment de faire mon propre Mapper abstrait en m'inspirant un peu de Hibernate (ça ne m'amuse pas de réécrire le même code dans tous mes mappers). Dès que ça aboutit je donnerais mon code ici. En attendant, pour créer des Mappers je m'inspire du GuestBookMapper du quickstart.

j'ai également le même problème... quand on veut utilisé plusieurs tables je ne sais pas ou mettre le code métier....

Salut à tous,

Je suis content que la discussion autour de la gestion du Model continue car on a encore du travail, je pense, pour comprendre comment utiliser au mieux Zend_Db.

Merci ramos pour ton exemple intéressant et bien expliqué, ça m'a motivé pour le coder histoire qu'on se rende compte de ce que ça donne, en utilisant un code organisé comme dans le Quick Start. J'ai choisi de développer le cas 1 que décrit ramos pour avoir d'un côté une liste d'auteurs, avec les livres qu'ils ont écris et de l'autre une liste de livres avec comme attribut leur auteur.

Mon application d'exemple est disponible à l'adresse http://bearnaise.net/~sphax3d/model-mapper-table.zip
Il faut regarder en particulier les fonctions fetchAll() et findByAuthor() dans BookMapper.php et AuthorMapper.php

Je suis bien sûr ouvert à toutes contributions pour améliorer cet exemple, en particulier pour rajouter des fonctionnalités intéressantes à implémenter avec cette organisation de trois fichiers par modèle :-) N'hésitez pas à proposer votre version de cette application d'exemple !

Quelques points encore obscurs pour moi :
- Quand ramos parle de "raisonner en terme de métier" auteurs et livres paraissent correspondre à des types de données, et pas à une "fonction" comme le Guesbook du Quick Start. Ces données seront donc des tables au niveau du stockage en BDD, donc je ne vois pas encore la différence... où alors j'ai mal compris :-)
- Je trouve que les fonctions __construct(), __set(), __get() et setOptions(), voire aussi les getter et les setter, dans les fichiers models/Author.php et models/Book.php, n'ont pas leur place dans ce fichier de modèle. D'après moi, elles permettent de faire fonctionner le modèle et n'ont pas d'intérêt à être répétés dans chaque fichier de modèle. Pourquoi ne pas créer un composant Zend_Model avec ces fonctions ? Ainsi chaque modèle étendrait cette classe... (un peu trop d'ambition ? :-))
- Pareillement, les fonctions setDbTable() et getDbTable() ne permettent que de faire fonctionner la structure des trois fichiers Model / Mapper / Table et donc n'ont rien à faire dans un fichier AuthorMapper.php ou ou BookMapper.php. Là encore je verrais plutôt ces fonctions dans une class Zend_Model_Mapper ou Zend_Model_DbMapper pour avoir plusieurs types de mapper... Enfin pour ça, c'est une simple idée, qui n'est peut-être pas bonne :-)
- Quel est l'intérêt d'avoir plusieurs mappers pour un modèle ? (setMapper() et getMapper())

En tout cas, je ne suis pas encore convaincu de cette solution Model/Mapper/Table. J'utilisais avant une solution du style Model/Table/Row qui convenait assez bien. J'appelais dans mon controller les fonctions définies dans une classe Model qui elles même appelaient les fonctions d'une classe Table (héritant de Zend_Db_Table_Abstract), pour par exemple utiliser find(), ou les fonctions d'une classe Row (héritant de Zend_Db_Table_Row_Abstract) pour par exemple définir l'attribut d'un seul élément (row).

Merci pour vos réponses !