EZPDO : Object-Relational Mapping en PHP

Lorsque l'on réalise une insertion dans la table, il n'est pas nécessaire de se soucier de nos clés primaires. EZPDO se charge de générer automatiquement la bonne valeur lors de chacune de nos insertions.

// Création du nouveau film
$film = $m->create('Film');

// Modification des attributs
$film->nom = 'Monkey Bone';
$film->synopsis = '...';
$film->note = 9;
$film->disponible = true;

// Insertion dans la base de données
$m->commit($film);

La méthode commit n'a pas forcément besoin d'être appelée si le paramètre auto_flush a été activé dans le fichier de configuration. Ce paramètre demande au gestionnaire de réaliser tous les enregistrements dans la base de données à la fin de l'exécution du script.

Il est également possible d'utiliser la méthode flush pour effectuer tous les traitements en attente.

$m->flush();

Normalement si tout s'est bien passé vous devriez avoir un nouveau film enregistré dans votre base de données.

Si une erreur se produit à ce niveau, vérifiez que le chemin d'accès vers vos classes devant contenir les données est correct.

Imaginons que nous voulions rechercher tous les films ayant une note égale à 10 et qui sont disponibles.

// Création d'un modèle pour les films à rechercher
$film = $m->create('Film');
$film->disponible = true;
$film->note = 10;
$film->nom = null;
$film->synopsis = null;

// On récupère la liste des films correspondant à nos critères
$listeFilm = $m->find($film)
if (!$listeFilm) {
    exit();
}
 
// Traitement sur nos résultats
foreach($listeFilm as $unFilm) {
    echo $unFilm->nom;
}

S'ils sont initialisés par le constructeur de l'objet, il est nécessaire d'affecter la valeur NULL aux attributs sur lesquels on ne souhaite pas faire de sélection. Dans le cas contraire, ces affectations ne sont pas nécessaires.

Cette méthode est simple, mais on remarque que ces requêtes sont également très limitées, il n'est par exemple pas possible de faire des recherches à partir de portions de nom. Si vous voulez le faire, il va falloir utiliser le langage de requête EZOQL que je présente un peu plus loin.

Pour supprimer un tuple dans la table, il faut utiliser la méthode delete.

$m->delete($unfilm);

Si l'on souhaite supprimer tous les tuples contenus dans la table, il suffit d'utiliser la méthode deleteAll.

$m->deleteAll('Film');

Il faut noter que lorsqu'il existe une association de composition entre deux tables, la suppression d'un tuple peut entrainer la suppression des autres tuples.

Il existe différentes manières pour modifier et accéder aux données stockées dans les classes.

$film->nom = 'Le grand bleu';
echo $film->nom ;

$film->setNom('Le grand bleu');
echo $film->getNom();

$film['nom'] = 'Le grand bleu';
echo $film['nom'];

Ces trois bouts de code effectuent exactement le même traitement.

Les mots-clés has et composed_of sont utilisés pour spécifier le type de relation entre les tables, respectivement l'agrégation et la composition.

Lorsque l'on utilise une agrégation, si un objet A est lié à un ou plusieurs objets B, lorsque l'on détruira l'objet A, aucun objet B ne sera détruit. Si par contre on utilise une composition pour lier les deux objets, EZPDO se chargera de détruire automatiquement tous les objets B liés par cette relation.

Les mots-clés one et many permettent de matérialiser les cardinalités des relations. one symbolise le fait qu'un tuple ne possède qu'une seule référence vers un tuple d'une autre table, many au contraire indique que le tuple pourra être lié à plusieurs tuples de l'autre table.

Reprenons notre base de données d'exemple. Pour matérialiser le fait qu'un film a un et un seul réalisateur et qu'un réalisateur peut réaliser plusieurs films, il faut rajouter les lignes suivantes :

class Film {
   /**
   * @orm has one Réalisateur
   */  
  public $realisateur;
}

class Réalisateur {
   /**
   * @orm composed_of many Film
   */
   public $film;
}

Dans notre cas le mot-clé one n'était pas nécessaire puisqu'il est utilisé par défaut lorsqu'aucun mot-clé n'est spécifié.

On peut également noter l'utilisation de composed_of pour l'attribut film de la classe Réalisateur. On indique ainsi que lorsque l'on supprimera un réalisateur tous les films qu'il aura créés seront également supprimés.

Nous venons de matérialiser une relation 1-n entre les deux tables. Voyons maintenant comment matérialiser le fait qu'un film ait plusieurs acteurs et qu'un acteur puisse jouer dans plusieurs films.

class Film {
   /**
   * @orm has many Acteur
   */  
  public $acteur;
}

class Acteur {
   /**
   * @orm has many Film
   */
   public $film;
}

Voilà notre relation n-n modélisée. C'est très simple à faire pourtant grâce à ces quelques lignes, EZPDO pourra automatiquement créer une table servant de jointure entre les deux tables. On peut noter qu'EZPDO permet également de modéliser des relations réflexives.

Maintenant que nous savons décrire nos associations, voyons comment associer facilement deux tuples ensemble et retrouver très facilement les tables liées les unes aux autres.

Tout d'abord pour associer à un tuple, un ou plusieurs tuples on utilise une affectation standard pour l'attribut matérialisant la relation. Si l'on souhaite associer plusieurs tuples à la fois on peut utiliser un tableau.

$film1 = $m->create('Film');
$film2 = $m->create('Film');
... // Initialisation des films

$acteur1 = $m->create('Acteur');
$acteur2 = $m->create('Acteur');
$acteur3 = $m->create('Acteur');
... // Initialisation des acteurs

$realisateur = $m->create('Realisateur');
... // Initialisation du réalisateur

// 
$film1->acteurs = array($acteur1, $acteur2);
$film2->acteurs = $acteur3;

$realisateur->films = $film1;
$film2->realisateur = $realisateur;

Dans notre exemple nous n'avons matérialisé des liens que dans un seul sens, il sera possible à partir d'un film de retrouver ses acteurs, mais pas dans le sens inverse. Si l'on souhaite le faire (ce qui sera probablement le cas) il y a deux solutions. Soit affecter également à chacun des acteurs les films, soit utiliser un nouveau tag pour notre attribut. Il s'agit du tag inverse qui prend en paramètre le nom de l'attribut dans notre classe qui contiendra notre association. Voilà comment il faudra modifier nos classes Film et Acteur

class Film {
   /**
   * @orm has many Acteur inverse(acteur)
   */  
  public $acteur;
}

class Acteur {
   /**
   * @orm has many Film inverse(film)
   */
   public $film;
}

Cette solution est très simple à mettre en place et simplifiera encore un peu le code.

Une fois que cela est fait, on risque sûrement à un moment d'avoir besoin de retrouver les tuples associés entre les tables. Comme précédemment cela se fait très facilement, en récupérant les valeurs des attributs.
Dans le cas d'une relation multiple, on pourra récupérer une collection contenant la liste des tuples associés.
L'attribut matérialisant notre relation contiendra les objets de nos tables. Il sera possible de les manipuler exactement comme n'importe quel autre objet, et par exemple de faire des mises à jour.
Voilà un court exemple d'utilisation :

// On souhaite afficher le nom de tous les films du réalisateur de ben-hur
foreach($benhur->realisateur->film as $unFilm) {
    echo $unFilm['nom'];
}

// Maintenant on souhaite renommer le réalisateur de Léon en Bob Morane
$leon->realisateur->nom = 'Bob';
$leon->realisateur->prenom = 'Morane';

Et voilà, aucune requête SQL pourtant en quelques lignes vous avez réalisé plusieurs jointures et des mises à jour.

En guise de conclusion sur les associations, je pense qu'il faut retenir que l'intérêt principal de l'ORM dans la gestion des associations est qu'il permet de les gérer comme de simples attributs de nos objets. Il n'est plus nécessaire d'effectuer des requêtes compliquées de mise à jour et de sélection pour retrouver nos valeurs.

Pour effectuer une requête, on utilise la méthode find du manager. Cette méthode nous renverra une collection contenant tous les tuples de nos tables correspondant à notre requête. Il est bien sûr possible d'avoir des critères lors des recherches.

// Recherche les réalisateurs dont le prénom est Bob
$realisateurs = $m->find("from Réalisateur where prénom = 'Bob'");

// Recherche tous les films contenant 'bleu' dans le nom
$films = $m->find("from Film as f where f.nom like '%bleu%'");

// Recherche les acteurs dont la date de naissance n'a pas été spécifiée.
$acteurs = $m->find("from Acteur where dateDeNaissance is null");

On remarque dans la deuxième requête l'utilisation du mot-clé as pour créer un alias de la table.

On peut également utiliser des paramètres dans les critères de recherche. Pour cela il faut remplacer la valeur par ? dans la requête et mettre la liste de nos valeurs à la suite.

// Affiche les acteurs nés après mon père et avant moi.
$acteurs = $m->find("from Acteur where dateDeNaissance < ? and dateDeNaissance  > ?", monAge, ageDeMonPere);

On peut trier par ordre croissant, décroissant et aléatoire. Si aucun ordre de tri n'est spécifié, ce sera l'ordre croissant qui sera utilisé par défaut.

// Affiche tous les films par ordre alphabétique
$films = $m->find("from Film order by Film.nom asc");

// Affiche les acteurs aléatoirement
$acteurs = $m->find("from Acteur where order by random()");

Il est possible également d'avoir plusieurs critères de tri dans une même requête.

// Affiche les réalisateurs triés par prénom croissant et par nom décroissant.
$acteurs = $m->find("from Acteur as a where order a.prénom, a.nom desc");

Il est enfin possible de limiter le nombre de résultats renvoyés par une requête.

// Affiche les cinq premiers réalisateurs
$realisateurs = $m->find("from Réalisateur order by nom  limit 0, 5");

Les fonctions d'agrégation disponibles sont les suivantes :

Voilà un exemple d'utilisation de la fonction AVG

$noteMoyenne = $m.find("AVG(note) FROM Film");

Il est bien sûr possible de combiner toutes les fonctions que nous venons de voir dans EZOQL pour produire des requêtes relativement évoluées.