Manipulez vos données avec Pomm
Un ORM PHP pour PostgreSQL

Les rubriques (actu, forums, tutos) de Développez
Tags
Réseaux sociaux


 Discussion forum

Le , par MaitrePylos, Responsable Livres
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 ?


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :


 Poster une réponse

Avatar de frinux frinux
http://www.developpez.com
Membre régulier
le 21/02/2013 11:05
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.
Avatar de MaitrePylos MaitrePylos
http://www.developpez.com
Responsable Livres
le 21/02/2013 11:08
Où as-tu lu 'Un ORM PHP pour PostgreSQL' ?
Avatar de frinux frinux
http://www.developpez.com
Membre régulier
le 21/02/2013 11:40
cf PJ
Avatar de MaitrePylos MaitrePylos
http://www.developpez.com
Responsable Livres
le 21/02/2013 12:02
oki merci.
Avatar de chanmix51 chanmix51
http://www.developpez.com
Invité de passage
le 26/02/2013 13:25
Citation Envoyé par frinux  Voir le message
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
Offres d'emploi IT
Chef de projets informatiques amoa
CDI
GECINA - Ile de France - Paris (75000)
Parue le 21/11/2014
Intégrateur web confirmé (h/f)
CDD Freelance
PAC Recrutement - Provence Alpes Côte d'Azur - prox. Aix-en-Provence (13)
Parue le 02/12/2014
Gestionnaire des systèmes d'information
Stage
Renault - Ile de France - Guyancourt (78280)
Parue le 03/12/2014

Voir plus d'offres Voir la carte des offres IT
 
 
 
 
Partenaires

PlanetHoster
Ikoula