Modèle et persistance

La première chose que l’on m’a apprise lorsqu’on m’a parlé de MVC, c’était que le M (pour model) devait contenir la logique « métier » de notre application. Quand on parle de métier, c’est bien ce qui est spécifique à l’application développée. La partie Modèle d’une calculatrice doit savoir calculer (Lapalisse si tu m’entends, elle est pour toi celle là), la partie Modèle d’une gestion de facturation doit savoir gérer les relances, les impayés, les factures … Bon bah très bien tout ça.

Et là c’est le drame, vous vous mettez à utiliser symfony et un des deux principaux ORM du monde PHP : Propel ou Doctrine. Tout d’abord vous trouvez ça chouette, vous pouvez faire un ->save() ou un ->delete() directement sur votre objet, la classe. Mais qu’est-ce que ça veut dire ça ? Ca veut dire que votre objet connait la façon dont il doit persister. Il est fortement couplé à la façon dont vous voulez l’enregistrer, dans notre cas dans une base de données.

C’est assez facile à voir, regardez le graphe d’héritage de votre objet, pour Doctrine tous les objets de votre modèle héritent de la classe Doctrine_Record. Et si, par le plus grand des hasards, vous voulez réutiliser votre logique métier dans une autre application PHP qui n’a rien à voir avec celle que vous développez avec symfony/Doctrine ? Vous êtes bons pour de jolis copier/coller.

DataMapper à la rescousse

L’idéal pour réaliser des M qui ne font que du M, c’est de n’avoir que des PPO (Plain PHP Object), c’est à dire des objets PHP standards (qui n’héritent pas d’une classe comme Doctrine_Record par exemple). Ces PPO doivent réaliser la logique métier de notre application (le M), et une autre partie de l’application doit pouvoir prendre ce PPO et le faire persister quelque part (système de fichier, base de données, …). C’est là qu’intervient le design pattern DataMapper. Il va permettre de faire le lien entre l’objet (l’Entity dans le jargon Doctrine2) et la façon dont il devra persister. Dans Doctrine2, c’est l’Entity Manager qui va réaliser le rôle de DataMapper avec sa méthode flush() qui sauvegarde les changements dans la base de données.

Unit of Work, le copain du DataMapper

La méthode ->flush() de l’EntityManager va permettre d’enregistrer les changements effectués sur les PPO dans la base de données. Ces changements auront été notifiés au préalable à l’Entity Manager par la méthode persist(). Cette méthode permet de dire à l’Entity Manager que l’on veut faire persister notre PPO passé en paramètre de la méthode. Ça se résume comme ça :

<?php
$user = new User;
$user->setName('Mr.Right');
$em->persist($user);
$em->flush();

Ici on informe l’Entity Manager (em), que l’on voudra faire persister les changements apportés à l’objet user via la méthode $em->persist($user). Les changements ne seront effectués dans la base de données qu’une fois la méthode ->flush() invoquée. Si nous avions fait plusieurs ->persist() différents avant de faire notre ->flush(), rien n’aurait encore été écrit dans la base. Mais alors, comment Doctrine fait pour garder trace de ces changements jusqu’au flush ? Il utilise le design pattern Unit of Work. Ce design pattern permet de garder trace de toutes les modifications apportées entre 2 flush(). Il met en place une sorte de transaction, mais au niveau des objets. C’est en partie son utilisation qui permet d’avoir un beau Data Mapper comme l’EM.

Conclusion

L’utilisation d’un DataMapper n’est pas vraiment nouveau dans le monde de la programmation : Hibernate l’implémente déjà pour Java et SQLAlchemy pour Python. En revanche, c’est une petite révolution dans le monde PHP. Si des fois vous préférez garder votre bon vieux Active Record, il existe aussi des solution en PHP : vous pouvez utiliser l’ORM Propel qui est toujours activement maintenu par François Zaninotto ou utiliser des implémentations du pattern Active Record réalisées avec Doctrine2 comme Doctractor ou ActiveEntity codé par l’équipe de Doctrine2. C’est deux derniers exemples montrent bien toute la flexibilité et la puissance de cette nouvelle version de Doctrine !

Wait and see mais en attendant voici la sélection de la semaine.

• Propel 1.4 stable
  C’est un peu l’annonce de la semaine. Propel 1.4 stable est sortie! Pas mal de nouveautés dont certaines reprises des bonnes idées de Doctrine, mais également quelques exclus. Peut-être un futur billet plus complet à ce sujet ;)
• Un joli thème wordpress
  Une fois n’est pas coutume, croisé au détour d’un clic, assez sobre mais bourré de petits détails.
• Un autre joli thème wordpress
  Comme quoi ya des semaines comme ça. Celui-ci est plus poussé graphiquement mais a un vrai potentiel je pense
• Event jquery sur la sélection de texte
  Fonctionnalité qui pourrait ouvrir la porte à quelques nouvelles possibilités sympa
• Un nouveau script de validation de formulaire
  Oui encore un. Ca faisait longtemps. Mais celui-ci est vraiment bien fini et permet de définir ses validations avec très peu de ligne js, tout étant calibré depuis le code html
• Memcache et le PHP
  Une petite explication sur Memcache et ses bienfaits pour le PHP
• Drag and share avec jQuery
  Une façon originale de penser le drag and drop et le partage sur les medias sociaux.
• Un compilateur javascript par Google
  C’est le lien qui a fait le tour du web, cette semaine. Le voilà décrit par dew, même s’il s’avère très compliqué d’être utilisé avec jquery, ca reste un outil assez novateur.
• Un nouvel ORM PHP
  Basé sur l’ORM de Ruby, voici un ORM dont on pourrait bien entendre parler prochainement.

On se rappelle tous (enfin je parle au passé, mais Propel n’est pas mort hein :p) qu’on avait tout à disposition dans le BasePeer de notre modèle, les accesseurs, les modificateurs et quasi toutes les méthodes dont on pouvait avoir besoin. Avec Doctrine, la donne a changé, tant cet ORM est codé différemment.

On se retrouve du coup un peu perdu parfois, sans trop savoir ce qu’on peut utiliser. Et là, il faut bien sûr jeter un œil à l’API Doctrine. Mais on le sait tous, on a pas toujours le temps! Du coup, au travers de mes recherches, j’ai trouvé quelques petites méthodes que j’utilise régulièrement et dont je vais vous parler.

Le modèle d’exemple

Afin d’illustrer au mieux les différentes fonctions, je vais prendre en exemple un modèle basique, une liste de lien:

MyLink:
  columns:
    name: { type: string(100), notnull: true }
    link: { type: string(255), notnull: true }
    description: { type: string(4000) }

Un save qui retourne un booléen

Parfois, lors de petites modifications, on a pas toujours le courage de faire un try/catch sur notre transaction. TrySave répond à cette problématique, en incluant directement le try catch sur le save et en retournant un booléen, true si l’enregistrement a bien été commité, false si une exception a été levée. Bien pratique!

• Documentation trySave
• Exemple:

  public function saveMyLink()
  {
    $link = new MyLink();
    $link->name = 'Amicalement-web';
    $link->url = 'http://www.amicalement-web.net';
   
    return $link->trySave(); // Retournera true si la sauvegarde a été effectuée, false sinon
  }

Le nom de la clé primaire

Oui des fois, quand on veut généraliser une méthode, on a besoin du nom de la clé primaire de notre model. (Dans le cas d’un unset en vue d’un embedForm par exemple).

• Documentation getIdentifier
• Exemple:

  $link = new MyLink();
  $link->getTable()->getIdentifier();

Exporter votre modèle en différents formats

Que se soit pour générer des XML destinés à une application tiers, ou du json pour votre module javascript, on a souvent besoin de nos modèles dans un format d’échange. Et bien Doctrine intègre cette fonctionnalité de base, en permettant des export en tableau php, xml, yml et json.

• Documentation exportTo
• Exemple

  $link = new MyLink();
  $link->name = 'Symfony Project';
  $link->link = 'http://www.symfony-project.org';
  $link->save();
   
  echo $link->exportTo('xml'); // Attention par défaut exporte aussi les relations de l'objets. Il faut mettre à false, le 2e argument si on veut conserver seulement notre objet en question

• Rendu:

  <?xml version="1.0" encoding="utf-8"?>
  <data>
    <id>1</id>
    <name>Symfony Project</name>
    <url>http://www.symfony-project.org</url>
    <description></description>
  </data>

Importer votre modèle en différents formats

Et oui parce que Doctrine fait les choses biens, la réciproque existe aussi et est toute aussi utile. Vous pouvez ainsi hydrater  un objet à partir d’un xml, json, ou yml grâce à la méthode importFrom

• Documentation importFrom
• Exemple:

  $json = '{"id":"5","name":"Doctrine Project","url":"http:\/\/www.doctrine-project.org","description":"Orm PHP"}';
  $link = new MyLink();
  $link->importFrom('json',$json);
  echo $link->name; // Affiche "Doctrine Project"

Pour ce qui est d’hydrater à partir d’un tableau php, il y a 2 méthodes pour ça: fromArray et hydrate. Leurs différences, c’est la façon de faire. La première utilise les modificateurs de notre modèle (permettant ainsi de passer par des modifications qu’on aurait pu apporter à ces méthodes « set ») alors que la seconde remplie directement les attributs de notre modèle.

• Documentation fromArray
• Documentation hydrate
• Exemple:

  // On surcharge le modificateur de la propriété $url pour rajouter 'http://' devant
  class MyLink extends BaseMyLink
  {
    public function setUrl($url)
    {
      parent::_set('url','http://'.$url);
    }
  }

  Puis maintenant nos 2 appels:

  $data = array('name' => 'Amicalement Web', 'url' => 'www.amicalement-web.net');
  $link1 = new MyLink();
  $link1->fromArray($data);
  echo 'link1='.$link1->url; // Affiche http://www.amicalement-web.net
   
  $link2 = new MyLink();
  $link2->hydrate($data);
  echo 'link2='.$link2->url; // Affiche www.amicalement-web.net

Post/Pre methodes

Comme je l’avais utilisé dans l’exemple du behavior Geographical, Doctrine met à disposition toute une série de méthodes en post et pré traitement de nombreuses fonctionnalités comme

• Sérialisation
• Désérialisation
• Sauvegarde
• Suppression
• Mise à jour
• Insertion
• Validation
• Hydratation

Leur documentation à la suite les unes des autre.

Libérer de la mémoire

La performance, sans être un axe principal a mon goût, doit rester dans la tête de chacun. Pour ça, Doctrine propose une méthode pour effacer un objet ainsi que toutes ses références de la mémoire de l’ORM. A utiliser principalement dans des boucles quand on veut juste faire un traitement sur un ensemble d’objets dont on ne voudra pas se resservir ensuite.

• Documentation free
• Exemple:

  // Exemple tiré de la documentation doctrine
  for ($i = 0; $i < 1000; $i++)
  {
      $object = createBigObject();
      $object->save();
      $object->free(true); // true pour libérer même les relations
  }

Hydrater plus efficacement

Et oui, on le crie pas sur tous les toits, mais on est pas obligé de récupérer des objets complets quand on fait une requête avec doctrine même si c’est le comportement par défaut.
Quand on veut simplement faire de l’affichage, parfois seules les données nous intéresse et donc dans un gain de mémoire, on peut changer le mode d’hydratation:

• Doctrine::HYDRATE_RECORD
• Doctrine::HYDRATE_ARRAY
• Doctrine::HYDRATE_NONE
• Exemple:

  $q = Doctrine_Query::create()->from('MyLink');
   
  // Comportement par défaut, retourne un tableau d'objet
  $results = $q->execute(array(),Doctrine::HYDRATE_RECORD);
   
  // Retourne un tableau associatif où les clés sont les noms des champs
  $results = $q->execute(array(),Doctrine::HYDRATE_ARRAY);
   
  // Retourne un simple tableau où les champs sont dans l'ordre qu'ils ont été appelés
  $results = $q->execute(array(),Doctrine::HYDRATE_NONE);

Cela reste le fruit de mes tests et études, si vous avez des remarques ou des corrections n’hésitez pas!

Et vous, vous avez quelque chose à partager sur les méandres de Doctrine?