par
naholyr » 08 mars 2007, 11:13
Des solutions ORM le permettent de façon transparente. J'utilise par exemple ezPdo dans plusieurs projets, cela me fait gagner énormément de temps puisque je ne fais plus aucune requête SQL pour la persistance des données (on perd bien sûr en performance). Imaginons qu'on gère une bibliothèque. On va gérer des objets Livre. Pour ajouter un livre à la bibliothèque j'aurai ce type de code :
$epm = epManager::instance();
// on charge notre bibliothèque (objet persistant unique, donc le résultat sera toujours un tableau de taille 1).
$bibliothèque = $epm->find('from Bibliotheque')[0];
// on crée le livre
$livre = $epm->create('Livre');
$livre->titre = "Titre du livre";
... etc ...
// on ajoute le livre à la bibliothèque
$bibliothèque->livres[] = $livre;
Et mon livre est ajouté à la bibliothèque. Quand je retournerai sur la page listant les livres :
$epm = epManager::instance();
$bibliothèque = $epm->find('from Bibliotheque')[0];
foreach ($bibliothèque->livres as $livre) {
echo $livre->titre . '<br/>';
}
Mon livre apparaîtra bien. Pas de session, pas de requête affichée ni dans le code métier, ni dans l'implémentation de la classe (il y a juste des commentaires /** @orm ... **/ au-dessus des déclarations d'attributs).
C'est le genre de chose permise en "standard" par Java, et rendu possible grâce à ce genre de librairie qui permettent la persistance des données objet de manière transparente. De base ça stocke l'objet en base de données, donc ça limite les performances. Il y a cependant quelques patchs permettant d'utiliser des extensions comme memcache qui permettront de garder l'objet dans la mémoire vive du serveur (l'objet est alors stocké en base ET en ram, la lecture se fait sur la ram, la modification se fait sur la ram et sur la base), et là autant dire qu'on va à l'inverse gagner en performance
Des solutions ORM le permettent de façon transparente. J'utilise par exemple ezPdo dans plusieurs projets, cela me fait gagner énormément de temps puisque je ne fais plus aucune requête SQL pour la persistance des données (on perd bien sûr en performance). Imaginons qu'on gère une bibliothèque. On va gérer des objets Livre. Pour ajouter un livre à la bibliothèque j'aurai ce type de code :[php]$epm = epManager::instance();
// on charge notre bibliothèque (objet persistant unique, donc le résultat sera toujours un tableau de taille 1).
$bibliothèque = $epm->find('from Bibliotheque')[0];
// on crée le livre
$livre = $epm->create('Livre');
$livre->titre = "Titre du livre";
... etc ...
// on ajoute le livre à la bibliothèque
$bibliothèque->livres[] = $livre;[/php]
Et mon livre est ajouté à la bibliothèque. Quand je retournerai sur la page listant les livres :[php]$epm = epManager::instance();
$bibliothèque = $epm->find('from Bibliotheque')[0];
foreach ($bibliothèque->livres as $livre) {
echo $livre->titre . '<br/>';
}[/php]
Mon livre apparaîtra bien. Pas de session, pas de requête affichée ni dans le code métier, ni dans l'implémentation de la classe (il y a juste des commentaires /** @orm ... **/ au-dessus des déclarations d'attributs).
C'est le genre de chose permise en "standard" par Java, et rendu possible grâce à ce genre de librairie qui permettent la persistance des données objet de manière transparente. De base ça stocke l'objet en base de données, donc ça limite les performances. Il y a cependant quelques patchs permettant d'utiliser des extensions comme memcache qui permettront de garder l'objet dans la mémoire vive du serveur (l'objet est alors stocké en base ET en ram, la lecture se fait sur la ram, la modification se fait sur la ram et sur la base), et là autant dire qu'on va à l'inverse gagner en performance ;)
