Discussion :

[Invité]

Bonjour,

je conçoit en ce moment l'architecture technique d'une application en PHP et je me heurte encore aux éternelles problématiques d'accès aux données. Je souhaiterai :
- ne pas être dépendant de la source de données (abstraction)
- ne pas écrire une ligne de SQL dans mon code
- générer automatiquement depuis mon modèle de données, les classes d'accès aux données des objets métiers de l'appilcation

pour cela, j'ai testé le package PEAR:ataObjects qui s'appuie sur le design pattern DataObject. Ce package réponds à toutes mes attentes sauf qu'il ne sait pas faire le mapping objet d'une liaison N-N entre 2 tables !
si bien que pour écrire des fonctions de recherche pour mon application, je reviens au point de départ : obligé d'écrire en dur dans le code, des requêtes SELECT avec les clauses JOIN qui vont bien pour parcourir la base de données.

est-ce que quelqun s'est déjà heurté à cette problématique ? est-ce que la volonté de ne pas écrire de SQL dans une appli qui s'appuie sur un modèle de données complexe (nombreuses jointures entre les tables) est complètement utopique ? est-ce que quelqun connait PEAR:ataObjects et/ou d'autres outils de ce type ?

merci pour votre réponse, je pense que c'est une problématique qui ne s'arête pas à PHP, mais qui concerne tous les langages objet.

[Eusebius]

est-ce que quelqun s'est déjà heurté à cette problématique ? est-ce que la volonté de ne pas écrire de SQL dans une appli qui s'appuie sur un modèle de données complexe (nombreuses jointures entre les tables) est complètement utopique ? est-ce que quelqun connait PEAR:ataObjects et/ou d'autres outils de ce type ?

A une époque j'avais commencé à écrire une couche de persistance du modèle objet dans le modèle relationnel, mais c'était vite devenu imbitable.
DataObjects ça fait quoi exactement ? Je peux mettre mon vieux projet à la poubelle ???

[ePoX]

C'est un peu utopique ton désire de ne plus écrire de SQL. Même dans les base de données Orientée Objet il existe un (même des) langage(s) de requete. En l'occurence l'OQL (Objet Query Langage).
Donc partant de la je voit mal comment tu vas pouvoir te passer completement d'un langage de requete, j'ai le sentiment que c'est même raté.

Sinon de tete :
- ezpdo
- propel

Autrement une piste sur ce qu'il existe http://wiki.cc/php/Object_Relational_Mapping


bbye

[Eusebius]

C'est un peu utopique ton désire de ne plus écrire de SQL. Même dans les base de données Orientée Objet il existe un (même des) langage(s) de requete. En l'occurence l'OQL (Objet Query Langage).
Donc partant de la je voit mal comment tu vas pouvoir te passer completement d'un langage de requete, j'ai le sentiment que c'est même raté.

Si on a juste besoin que nos objets soient persistants, on peut se contenter de requêtes SQL simples et automatisées, i.e. qu'on a pas besoin d'écrire. Mais forcément, c'est pas des applications où on exploite toute la puissance du modèle relationnel...

[Invité]

Eusebius : DataObject permet principalement de :
- générer automatiquement le code des classes d'accès à des tables de la BDD
- faciliter l'accès en CRUD aux objets métier d'une application (pas de SQL pour des opérations simples) en fournissant une couche d'abstraction de l'accès à la source de données
(http://pear.php.net/package/DB_DataObject/)

En ce qui concerne Java et d'après ce que j'ai lu dans les docs, le framework Hibernate de JBoss permet de décrire un mapping Objet/Relationnel assez avancé (y compris les liaisons n:m !) et de se passer de SQL pour la plus part des opérations !

ePoX : je suis bien d'accord qu'à un moment donné, une application doit bel et bien dialoguer avec un langage de requête particulier pour accéder à ses sources de données. Ce que je veux soulever comme idée, c'est qu'il doit certainement être possible que l'application génère "automatiquement" les requêtes adéquattes d'après une description du modèle de données et de ses relations avec le modèle objet de l'application. (cf. Hibernate pour Java)

Je pense que ce genre de solution permet de :
- gagner en temps et en confort de développement
- faciliter la maintenance de l'application
- améliorer la qualité et la fiabilité du code
- optimiser l'architecture de l'application

merci pour le lien vers l'état de l'art du mapping O/R en php, je vais regarder ça de plus près