Aussi loin que je comprenne ton design (je ne suis pas dev PHP), chaque objet MyObject correspond exactement a une (et une seule) table. Et les MyMap permettent regrouper ces objets cote à cote avec des bon tableaux à l'ancienne. C'est bien, mais si on danse mais si tu veut faire du relationnel ?
ORM signifie « Object Relation Mapping » : le but est avant tout d'abstraire les relations entre les objets. S'ils s'agissait seulement de saupoudrer les noms de tables et colonnes d'une pincée de syntaxe objet-like, on aurait surement appelé ça OTR (comme object table mapping).
Pour rester dans les exemples bateau, imagine que j'ai une entité "Utilisateur" et une entité "Addresse" (un Utilisateur ayant une seule Addresse, pour
faire simple). Je souhaite évidement pouvoir faire des choses du type :
Dans cet exemple on voit comment la relation pourrait être "abstraite" de la couche de persistance. En outre on aimerais pouvoir charger paresseusement (lazy loading) les objets et leurs attributs. Surtout lorsqu'on va sélectionner en profondeur (ex. ne pas charger toute les tables traversées (en plus, a coups de "SELECT *" !) en mémoire lorsqu'on fait un $user->client->address->town->getPostcode() sur un objet précis alors que pour ses congénères on n'utilise que $user->getClient()).
Si j'ai bien compris, pour le moment, l'utilisateur doit gérer ces relations à la main en écrivant ses requêtes et en agrégeant/associant manuellement les objets d'une même « ligne » (sic) du tableau MyMap, et en moulinant à l'ancienne pour reconstruire les liens en deréférençant les fkeys. Mais alors, quel intérêt d'un ORM (ou même, d'une vue objet) ?
> Le design pattern de pmo est documenté
J'ai lu le manuel indiqué en lien dans le journal (ici c'est culture Unix, alors si le man ne documente pas tout et qu'il faut lire des divx pour connaitre l'API...), mais je crois que tu n'avais pas compris mes remarques.
> PMO implémente par exemple active record, et fait même plus que cela [...]. PMO est plus souple que ADOdb [...] et les autres ORM PHP car c'est une API qui se concentre sur l'abstraction objet et non un framework qui va faire tout et n'importe quoi.
Et sinon ça va les chevilles ?
> PMO utilise PDO en couche d'abstraction, il permet donc d'utiliser Oracle, interbase, postgrsql, mysql
Ce que je voulais dire, c'est qu'ADOdb offre une API permettant de s'affranchir des petites différences de syntaxe SQL entre les divers moteurs (ce n'est pas seulement une façon d'unifier les drivers sgbd de php). Enfin bon c'est assez secondaire par rapport aux autres problèmes de PMO.
[^] # MultiDeskOS inside
Posté par herodiade . En réponse au journal PMO v 0.07 déjà. Évalué à 2.
ORM signifie « Object Relation Mapping » : le but est avant tout d'abstraire les relations entre les objets. S'ils s'agissait seulement de saupoudrer les noms de tables et colonnes d'une pincée de syntaxe objet-like, on aurait surement appelé ça OTR (comme object table mapping).
Pour rester dans les exemples bateau, imagine que j'ai une entité "Utilisateur" et une entité "Addresse" (un Utilisateur ayant une seule Addresse, pour
faire simple). Je souhaite évidement pouvoir faire des choses du type :
$user = Utilisateur::getByName("Mickael Kael");
$user->address->setTown("Muflin");
$user->save();
Dans cet exemple on voit comment la relation pourrait être "abstraite" de la couche de persistance. En outre on aimerais pouvoir charger paresseusement (lazy loading) les objets et leurs attributs. Surtout lorsqu'on va sélectionner en profondeur (ex. ne pas charger toute les tables traversées (en plus, a coups de "SELECT *" !) en mémoire lorsqu'on fait un $user->client->address->town->getPostcode() sur un objet précis alors que pour ses congénères on n'utilise que $user->getClient()).
Si j'ai bien compris, pour le moment, l'utilisateur doit gérer ces relations à la main en écrivant ses requêtes et en agrégeant/associant manuellement les objets d'une même « ligne » (sic) du tableau MyMap, et en moulinant à l'ancienne pour reconstruire les liens en deréférençant les fkeys. Mais alors, quel intérêt d'un ORM (ou même, d'une vue objet) ?
> Le design pattern de pmo est documenté
J'ai lu le manuel indiqué en lien dans le journal (ici c'est culture Unix, alors si le man ne documente pas tout et qu'il faut lire des divx pour connaitre l'API...), mais je crois que tu n'avais pas compris mes remarques.
> PMO implémente par exemple active record, et fait même plus que cela [...]. PMO est plus souple que ADOdb [...] et les autres ORM PHP car c'est une API qui se concentre sur l'abstraction objet et non un framework qui va faire tout et n'importe quoi.
Et sinon ça va les chevilles ?
> PMO utilise PDO en couche d'abstraction, il permet donc d'utiliser Oracle, interbase, postgrsql, mysql
Ce que je voulais dire, c'est qu'ADOdb offre une API permettant de s'affranchir des petites différences de syntaxe SQL entre les divers moteurs (ce n'est pas seulement une façon d'unifier les drivers sgbd de php). Enfin bon c'est assez secondaire par rapport aux autres problèmes de PMO.