PostgreSQL / PHP Object Model Manager

[MaitrePylos]

Bonjour, voici un article de Grégoire HUBERT sur son outil POMM

Pomm est un gestionnaire de modèle objet dédié au moteur de base de données PostgreSQL. Qu'est-ce qu'un gestionnaire de modèle objet ?

C'est avant tout un hydrateur d'objets qui utilise un convertisseur entre PHP et PostgreSQL pour assurer qu'un booléen dans Postgres sera vu depuis PHP comme tel, de même pour les tableaux, le type clé -> valeur 'HStore', les types géométriques, XML, JSON, etc.

Cette fonctionnalité de conversion est très importante, car le typage dans PostgreSQL est un élément incontournable de la définition du schéma par contrainte. La possibilité d'enrichir PostgreSQL avec des types personnalisés est prise en compte.

C'est également un gestionnaire de modèle orienté objet car Pomm crée des classes de mapping qui lient les structures SQL avec des objets PHP. Nous verrons là encore les grosses différences entre Pomm et les ORM classiques et comment utiliser la puissance du SQL de Postgres au service d'une petite application.

Qu'en pensez-vous ?
L'utilisez-vous ?

[frinux]

C'est quand même formidable de lire le titre "Un ORM PHP pour PostgreSQL" et, quand on arrive sur la page d'accueil du projet, lire "Pomm is not an ORM"...

Pour ma part je ne suis pas fan de ce genre d'outil, qui est trop lié à une base de donnée précise.

[MaitrePylos]

Où as-tu lu 'Un ORM PHP pour PostgreSQL' ?

[frinux]

cf PJ

[MaitrePylos]

oki merci.

[chanmix51]

Envoyé par frinux

Pour ma part je ne suis pas fan de ce genre d'outil, qui est trop lié à une base de donnée précise.

Bonjour Frinux,

La mode est effectivement à l'abstraction de la base de données qu'on appelle aujourd'hui « couche de persistance de données ». Cela, à mon sens pose plusieurs problèmes d'ordre pratique car la base de données est la charnière entre le monde physique (comment je stocke sur le disque, structure et retrouve les données) et le monde virtuelle (code) dans lequel les programmeurs se réfugient.

S'abstraire de sources de données peut avoir un sens sur un serveur d'applications où un service de gestion des données va gérer des bases de données (relationnelles, hiérarchiques), des flux web services etc. Ce service va rester opérationnel entre chaque sollicitation et entretenir une couche de cache qui va d'une part permettre d'améliorer les performances mais aussi délivrer la même instance d'un objet métier pour deux mêmes requêtes.

Dans le monde PHP il n'en est pas de même car l'ensemble de la couche d'abstraction est interprétée à chaque appel et la majorité des projets n'utilisent qu'une source de données : une base de données relationnelle (ou un ersatz). Dans ces conditions, un ORM ne va permettre de profiter que du plus petit commun ensemble de fonctionnalités partagé entre les différents moteurs.

C'est un peu comme si j'avais un 4x4 et une formule 1, que je les abstrayais en « véhicule » et ne leur laissais que "avancer, reculer, tourner et freiner". L'un va avoir un rendement très mauvais sur autoroute, l'autre sur terrain gras sans qu'on puisse profiter des avantages propres à chacun quand ils sont sur leur terrain de prédilection. Développer comme cela revient à demander à un "véhicule" d'aller d'un point A à un point B sans tenir compte du terrain.

Dans certains cas, il se peut que l'on ait besoin de s'abstraire des sources de données. Si vous faîtes un moteur de blogs, une plate-forme CMS ou autre produit générique par exemple car vous ne savez pas sur quelle socle technique sera déployée votre application. Le prix à payer pour cela est une couche d'abstraction en PHP lente et peu optimisée. Pourquoi payer ce prix sans avoir ce besoin ?

Amicalement,
Grégoire