Modélisation ORM

ViPHP
ViPHP | 4674 Messages

23 avr. 2008, 11:12

Note de Zeus : Extrait de http://www.phpfrance.com/forums/voir_sujet-239895.php
Hey :),

En fait avec Cyrano et mcorgnet, on travaille sur un projet d'ORM, et on se pête les dents sur 2 ou 3 trucs. Personnellement, j'aimerais avoir vos avis sur l'utilité d'un ORM, quels sont les problèmes que vous avez rencontré ? Pourquoi ? En gros, vos avis très généraux.

Désolé si je te pourris ton sujet mcorgnet, mais on reste quand même dans l'essentiel :).
« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »

Hoa : http://hoa-project.net (sur @hoaproject).

Mammouth du PHP | 514 Messages

23 avr. 2008, 11:19

Ptit con !

C'était une question pro !

(maudis sois tu)

ViPHP
ViPHP | 4674 Messages

23 avr. 2008, 11:44

Hihi. Bon bah un modo pour ouvrir un nouveau sujet, merci ;-).
« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »

Hoa : http://hoa-project.net (sur @hoaproject).

Administrateur PHPfrance
Administrateur PHPfrance | 3131 Messages

23 avr. 2008, 13:20

Bah, avant de vous lancer dans le dév d'un ORM, vous voulez pas plutôt contribuer à Doctrine ou Propel ?

Parce qu'autant questions forums & cie ça me gêne pas que les gens perdent leur temps à faire leurs dévs dans leur coin vu qu'on a déjà pas mal de solutions très performantes. Mais au niveau des ORM il y a du boulot et j'ai l'impression que ce serait du gachis de main d'œuvre que de se lancer dans un projet alors que d'autres ont déjà tout ce qu'il faut comme base et manquent de quelques fonctionnalités avancées qu'il suffirait de prendre le temps d'implémenter.

M'enfin pour répondre à la question ce qui me manque dans un ORM ce serait la puissance des jointures "auto-hydratées" et le "DQL" de Doctrine dans Propel.
Ou bien l'API "Criteria" et les "Behaviors" de Propel dans Doctrine.



Mais bon je comprends, c'est toujours plus difficile d'améliorer le travail d'autrui que de tout faire soi-même. Moi-même je préfère faire mon pain plutôt que de chercher *la* boulangerie qui me va bien. Mais hein honnêtement, c'est le choix de la facilité ;)

ViPHP
ViPHP | 4674 Messages

23 avr. 2008, 13:33

Un autre avantage à refaire les choses toi-même est d'apprendre, et c'est le premier but de ce groupe de travail :).

Est-ce que la rapidité d'exécution des ORM existant ne mettent pas en péril les performances de l'application ? Est-ce que c'est intuitif de penser BDO ? Qu'est-ce ça apporte au niveau production ? Qu'est-ce qui est bien, mauvais, gênant, génial ?

:)
« Un handicap est le résultat d'une rencontre entre une déficience ou différence et une incapacité de la société à répondre à celle-ci. »

Hoa : http://hoa-project.net (sur @hoaproject).

Mammouth du PHP | 19672 Messages

23 avr. 2008, 19:33

Comme je suis un peu concerné par le sujet, je vais reproduire ici l'essentiel de ce qui a poussé Hywan à poster ce sujet.
En essayant de voir le problème globalement, j'en arrive à une première conclusion quant aux types de développement que l'on peut mener. Ils sont essentiellement de deux types. D'une part on peut développer des outils d'aide à la conception, d'autre part on peut mettre au point des outils de production.

Dans le cas des outils de production, il m'apparaît prioritaire de s'interroger sur la pertinence du travail lorsqu'on veut créer telle ou telle nouvelle fonctionnalité. L'intérêt de la création d'un outil d'ORM à cet égard me semble de plus en plus incertain. Un tel outil en effet doit permettre d'améliorer les performances techniques globales de l'application créée. Le but à poursuivre devrait donc être de limiter l'utilisation des ressources système autant que faire se peut.

Le but général de l'ORM est d'automatiser au maximum un système de requêtage SQL en établissant une sorte de cartographie de base de données dans le but de générer dynamiquement les requêtes nécessaires à un moment ou un autre dans le déroulement du programme. Si ce but peut faciliter le développement de cette application, il m'apparaît en revanche que non seulement il n'améliore pas les performances mais également que ça va la ralentir en utilisant davantage de ressources. L'intérêt d'un tel système tombe complètement si on réalise qu'en fin de compte, pour une application donnée, le modèle de données n'évoluera plus ou pratiquement plus. La structure des tables, vues et autres procédures stockées ne subira plus de modifications en dehors de corrections ou d'ajouts ponctuels de fonctionnalités nouvelles. Dans cette optique, il ne faut pas un doctorat en mathématiques quantique pour se rendre compte que refaire la cartographie à chaque nouvelle requête va complètement à l'encontre du but poursuivi à l'origine. Cette cartographie n'a besoin d'être générée qu'une seule fois au lancement puis éventuellement refaite en cas de modification d'un élément du modèle de données. Un outils d'ORM ne peut, en conclusion, que se classer comme un outil de conception et d'aide au développement. Et l'intégrer dans un quelconque framework devient également un non-sens.
Voilà, les avis et/ou objections seront bienvenus :)
Codez en pensant que celui qui maintiendra votre code est un psychopathe qui connait votre adresse :axe:

Administrateur PHPfrance
Administrateur PHPfrance | 3131 Messages

23 avr. 2008, 19:44

Aucun ORM du marché ne refait la «cartographie» à chaque lancement ;)

Doctrine et Propel génèrent du code (SQL et classes PHP) à partir d'un schéma.
ezPdo produit un fichier de "compilation" où il stocke tout un tas d'infos qu'il ne recalcule plus.
Je ne sais pas comment font les autres, mais c'est évident que cette opération ne doit être faite qu'à la demande.