Zend FR

Tu as raison Moimeme, j'ai implémenter la solution la plus facile, et qui est loin d'être la meilleur au niveau performances. J'ai d'ailleurs trouvé une solution récemment pour ce genre de requête : on fait une requête sur chaque table et on les assemble après avec une boucle pour créer les objets qu'il nous faut.
Je viens de l'implémenter dans mon exemple, et elle sera plus rapide si on sélectionne beaucoup d'enregistrements, mais on peut peut-être encore l'optimiser (quelqu'un a une idée ?). La nouvelle version est disponible à l'adresse http://bearnaise.net/~sphax3d/model-mapper-table-2.zip . J'ai ajouté des fonctions fetchAuthors() et fetchBooks() qui récupèrent simplement les auteurs et les livres, sans récupérer les livres de chaque auteur ou les auteurs des lives... compris ? :-p Par contre dites-moi si là encore ce n'est pas une bonne solution :-)

J'attend vos remarques !

Personnellement, je n'utilise pas Zend_Db_*, donc je ne peux pas vous aider concernant les requètes SQL.

J'utilise Doctrine, et c'est que tu bonheur.
En 2 requètes :

$books = Doctrine::getTable('Book')->findAll();

foreach ($books as $book) {
  foreach ($book->Authors as $author) { // Requête inplicite
  }
}

En 1 seule :

$books = Doctrine::getTable('Book')->createQuery()->lefjoin('Book.Author')->execute();

foreach ($books as $book) {
  foreach ($book->Authors as $author) {
  }
}

Ça nous aide pas beaucoup tout ça revenons à nos mapper, facade et autres objets metiers ...

kreatik a écrit:

Ah pas mal cette reflexion tu as pas un petit peu de code pour illustrer tout ça ?

Le coder du quickstart illustre bien le propos précédent il me semble à moins que l'objet métier ne fasse pas de requettes dans plusieurs tables...

Bonjour,

Je relance ce débat intéressant.

Il faut pousser la réflexion encore un peu plus loin que le Mapper.

Le rôle du Mapper, comme tout le monde l'a compris, est de transformer un objet Métier vers la persistance, où de construire un objet métier depuis la persistance.

Dans le cas du QuickStart ZF, nous avons Controller > Modèle (métier) > Mapper -> Zend_Db (persistance).

Si la transformation de l'objet métier vers la persistance nécessite des requêtes sur plusieurs tables, c'est donc du ressort du Mapper.

Mais est-ce suffisant ? La question est surtout de déterminer le rôle de chaque partie.

Les développeurs oublient souvent que la logique applicative, la logique métier et la persistance sont bien 3 éléments distincts.

La logique applicative, c'est ce que mon application peut et doit faire.

La logique métier, c'est l'organisation des objets répondant au problème du métier. Des représentations concrètes des entités/acteurs du métier avec leurs propriétés et leurs contraintes.

La persistance, c'est l'organisation de ma base de données.

Le controller doit-il manipuler directement les Mappers ?

Pour moi la réponse est non. Le controller détermine les interactions entre l'utilisateur et le déroulement des opérations. Donc un ensemble d'actions possible, les interactions entre elles, le déclenchement des opérations et le résultat à donner à l'utilisateur.
C'est le Front end.

Une couche supplémentaire est pour moi nécessaire pour déterminer ce que doit pouvoir faire l'application. Une cinématique entre le Front end et la Back end.
Cette couche devrait porter la logique de l'application. Un ensemble de méthodes répondant à ce que nous attendons de l'application. Elle devrait être capable de recevoir des objets métiers du controlleur et de restituer des objets métiers au controlleur.
C'est cette couche qui devrait assurer la rencontre entre les objets métiers et la persistance. Ce serait donc à elle de manipuler le Mapper.

C'est le pattern Service Layer. (qui n'est pas sans rappeler les webservices)

Ce pattern permet de découpler totalement le front du back et de la persitance. Il permet, avec une bonne documentation, aux développeurs du front d'avancer en ignorant totalement l'organisation du métier et de la base de données. Il devient donc "facile" de récupérer toute la logique de l'application et de la porter vers un autre front end.

Là où moi j'ai un peu plus de mal, c'est faire la différence entre ce pattern et le pattern "Facade". Je connais théoriquement la différence, mais en pratique, il m'est difficile de faire un choix et de bien déterminer les avantages et les inconvénients de chacun. Le pattern Service Layer répond très bien aux tendances d'aujourd'hui et permet de facilement mettre à disposition des Webservices.

Mais la façade dans tout ça ?

Quand à la proposition de Zend. Est-ce que leur Mapper n'assure pas certains fonctions qui ne lui reviennent pas ?


A+ benjamin.

Sympa

Ca va permettre d'avoir un oeil sur l'ensemble de Zend_Application et des méthodes disponibles.

Mais dans mon cas, où veux-tu en venir ? Tu crois que les couches de services devraient se comporter comme des Resource de Zend_Application ?

En passant, toi qui as aussi implémenté le pattern Facade (avec un système de composants pratique en plus), que penses-tu du pattern Service Layer ?

J'ai instinctivement envie de l'implémenter comme une multi-façade, c'est à dire un système d'activation de Services, puis ensuite des ajouts de services (composants) à la demande.

Du genres

$this->_services->addService("un service");

Ou même du singleton, un peu à la manière du registre.

J'avance un peu à l'aveugle. Je n'avais implémenté que la Facade jusqu'à maintenant

A+ benjamin.

Dernière modification par Delprog (18-07-2009 15:24:00)

Moimeme a écrit:

Excellent exemple sphax c'est deja plus parlant de partir sur du concret.

Un truc qui me saute aux yeux c'est que lorsque tu récupère les résultats des bouquins tu fais une requête sur l'auteur.

Code:

public function fetchAll() {
        $resultSet = $this->getDbTable()->fetchAll();
        $books = array();
        foreach ($resultSet as $row) {
            $author = new Default_Model_Author() ;
            $author->getMapper()->find($row->author_id, $author) ;
.../...

Donc si tu récupère des centaines de livres tu vas avoir des centaines de requêtes de faite ... aille aille coté perf.

Aurais-je loupé un truc ?

Je me demande si utiliser une façade qui manipule des zend_table et zend_row et communique avec les controlleurs n'est pas plus simple et aussi efficace.

Re-bonjour,

De mon coté, voici la seule manière que j'ai trouvé pour avoir un Mapper qui fait des jointures et évite donc de faire une requête par "row" :

public function getAllNews() 
{        
    $table = $this->getDbTable();
    $select = $table->select()
                    ->setIntegrityCheck(false)
                    ->from(    array('n' => 'ox_news'))
                    ->join(    array('m' => 'ox_members'), 'n.news_member_id = m.member_id','*');
    $resultSet = $table->fetchAll($select);

    ...
    ...
}

Je ne trouve pas ça très propre et de plus, on perd tout l'intérêt de déclarer les referencemap etc dans "la classe de passerelle aux données".

Personne n'a exemple concret de Mapping avec une jointure ?

si tu peux utiliser les méthodes __get et __set qui sont appelées lorsque on fais un get ou un set sur un attribut (même si celui-ci n'existe pas dans la classe)

class Test
{
   private $_privAttr;
   public $pubAttr.

   public function __set($name, $value)
   {
      switch ($name) {
      case : 'privAttr':
          $this->_privAttr = $this->myProtectValueMethod($value);
          break;
      case 'pubAttr':
          $this->pubAttr = trim($value);
          break;
      case 'otherAttr':
          $this->_privAttr = $this->myProtectValueMethod(trim($value) . $this->pubAttr);
          break;
      }
   }
}


$t = new Test();
$t->pubAttr = 'toto';
$t->privAttr = 'titi';
$t->otherAttr = 'tata';

ces appet vont passer par le __set
A+JYT

slaughter a écrit:

De mon coté, voici la seule manière que j'ai trouvé pour avoir un Mapper qui fait des jointures et évite donc de faire une requête par "row" :

Code:

public function getAllNews() 
{        
    $table = $this->getDbTable();
    $select = $table->select()
                    ->setIntegrityCheck(false)
                    ->from(    array('n' => 'ox_news'))
                    ->join(    array('m' => 'ox_members'), 'n.news_member_id = m.member_id','*');
    $resultSet = $table->fetchAll($select);

    ...
    ...
}

Je ne trouve pas ça très propre et de plus, on perd tout l'intérêt de déclarer les referencemap etc dans "la classe de passerelle aux données".

Personne n'a exemple concret de Mapping avec une jointure ?

C'est ce que je faisait dans ma classe Model à l'époque de la 1.7.
Là je me lance avec le 1.9 et je suis un peu pommé avec ces 3 fichiers pour 1 model.

Je pense faire comme toi dans mon mapper

Salut, Padraic Brady vient de rajouter 2 chapitres intéressants sur son livre en ligne "Survive the Deepend" concernant la création du modèle et du mapper.

A +

Coucou,
Petit up, qui - je pense - s'impose.

Les documentations Zend depuis la 1.8 n'ont pas évoluées pour proposer de réels solutions aux problèmes ci-dessus présentés.

Pour résumer le topic, il s'agit de comprendre comment réaliser quelque chose d'intelligent avec les Model, le Mapper et le DbTable.

Trois problématiques sont ressorties :
- La dépendance entre diffèrent objet, de la relation 1-1 à N-N.
- L'héritage de table.
- La chargement optimisées de données qui se rapproche des dépendances entre objet.

Il a été donné l'utilisation du partern Service Layer pour le contrôle des Mapper. C'est à mon avis un autre problème, qui ici est un problème de droit d'accès aux données.

De nombreuses personnes se rejoignent pour dire qu'il faut réaliser les appels SQL au niveau des Mapper. Cela inclus les jointures. Dans ce cas QUID des références/dépendances dans les DbTables ? QUID des surcharges ou création de fonction dans les DbTable ?

Aussi, en effectuant les jointures au sein des Mappeurs, ceux-ci se retrouveront avec des données qui ne sont pas forcement de leurs ressorts.
Exemple avec les News et les Membres

public function getAllNews() 
{        
    $table = $this->getDbTable();
    $select = $table->select()
                    ->setIntegrityCheck(false)
                    ->from(    array('n' => 'ox_news'))
                    ->join(    array('m' => 'ox_members'), 'n.news_member_id = m.member_id','*');
    $resultSet = $table->fetchAll($select);

    ...
    ...
}

Ici, le Model_Mapper_News aura en sa possession des informations sur les Membres. Il faut donc que ces informations soient données aux Model_Mapper_Membre pour que celui-ci puisse traiter la logique métier de ces objets.

Pour rester dans les dépendances, il n'existe aucun système qui permet de récupérer N niveau de dépendance. Système qui devrai gérer les boucles récursive qui peuvent apparaitre avec les liaisons N-N.


Concernant l'héritage de table, j'ai réalisé un topic dessus. Sujet qui ne donne malheureusement aucune réponse mais que des questions.

Une réflexion intéressante a été donnée par Delprog


---
De mon coté, je suis débutant Zend.
Mais pour réaliser une application ayant besoin d'héritage de table, et un full loading contrôlé j'ai procédé ainsi :
- Les models sont simples, ils appellent un mapper pour les méthodes CRUD uniquement.
- Les mappers contiennent des fonctions de recherches spécifiques à l'objet associé. Exemple avec un fetchAll, fetchByAuthor...
Une fonction fillObject permet de remplir un objet à partir d'un Rowset; cette fonction appelle d'autres Mappers lorsqu'il a des dépendances.
Chaque mapper contient les méthodes isAllowDependencie (), getNextNumAllowDependencie () et setNumAllowDependencie ().
Grâce à ces méthodes, je peut savoir si je dois rechercher ou non mes dépendances d'objet. Ce qui évite d'avoir un full loading qui charge la totalité de la base de donnée juste pour un Item.
La méthode fillObject configure les mappers dépendants avec getNextNumAllowDependencie qui est une simple fonction qui décrémente un index de 1 à chaque appel. Lorsque l'index est égal = 0, alors isAllowDependencie retourne faux, et le Mapper ne charge pas les dépendances.
Par défaut, les mappers ont 1 comme valeur de nextNumAllowDependencie, ce qui signifie que lorsque l'on charge un item, on charge l'item ainsi que ces dépendances de 1° niveau.
Cette méthode fonctionne plutôt bien, mais est totalement non userfriendly. Je cherche un système d'automatisation pour le chargement des dépendances N-N.

Concernant l'héritage de Table, les Models héritent les uns et des autres. Et les Mappers s'occupent d'appeler le Mapper "parent" de l'objet pour les opérations CRUD.

Tout cela est bien jolie, fonctionne... Par contre, la maintenance est lourde.
Mais surtout, j'ai One milliard d'allers/retours SQL qui pourraient être évités avec des jointures.

L'utilisation d'un cache au niveau de mon pattern Service Layer améliore les performances.. Mais il s'agit là de rustine.


Où en etes-vous au sein de cette réflexion ?
Le sujet date un peu, vous avez peut-être des solutions ?

Dernière modification par armetiz (09-03-2010 12:19:24)