Discussion :

[dorian53]

Bonjour,

Je viens de tomber sur un article qui essaie d'envisager l'avenir de MySQL

Pendant longtemps, il a manqué pendant longtemps de frameworks dans le développement PHP, pour avoir une vraie modélisation objet, et une couche ORM qui permette de rendre une application indépendante de sa base de données.

Depuis deux ou trois ans, ce n'est plus le cas, grâce à différents frameworks. Mais tous les produits n'ont pas encore suivi le mouvement, et beaucoup d'entre eux sont encore dépendants de MySQL. Il faut mettre en priorité cette dissociation.

À partir de cette fin d'interview je souhaites poser un contre argument à un discours auquel j'adhère pourtant entièrement au sujet de l'ORM.

Sur l'extrait de phrase mis en gras, que répondriez-vous à la remarque suivante :

Oui, l'application devient indépendante de la base de données. C'est pratique lorsque l'on souhaite volontairement changer de solution ou lorsqu'un projet vient à disparaitre.

Mais de l'autre coté on devient très dépendant de notre solution ORM si elle n'est pas intégré au langage nativement. Nous dépendons de la pérennité de notre framework. Je pense notamment à titre d'exemple à Zend_Db qui vient d'être abonné.

Dans le deux situations l'application est à retrvailler. La question est la suivante vaut-il mieux être dépendant de sa base de données ou de son framework d'ORM ?

Dorian

[Hephaistos007]

Je vois plusieurs sous-discussions.

D'une part, l'indépendance vis-à-vis d'un SGBD. Cela, on sait le faire depuis 10 ans à travers la spécification ODBC. Pour le cas spécifique de PHP, on peut citer PDO. Donc la question est déjà réglée.

D'autre part, la correspondance objet-relationnel (Object-relationnel mapping), qui est pourtant une évidence, mais qui a mis du temps à se pratiquer. Ensuite, classiquement, soit on code cette correspondance soi-même, soit on utilise des frameworks pour accèler ce travail (ex: Hibernate et consors). La question est là aussi réglée.

Conclusion : je ne sais pas quelle est la problématique soulevée. Quant à dire que tu es lié au destin d'une framework, c'est la dure réalité d'un développeur. C'est valable pour une API et même un langage.

[dorian53]

La problématique de la question repose sur la pérennité des solutions.

Le cas de Zend_Db_Table en est un parfait exemple. Cette couche ORM pourtant issu du framework "référence" des spécialistes en PHP est abandonnée par l'équipe de développement. Résultat, l'ensemble des projets ayant investi sur cette couche d'abstraction se retrouve au pied du mur. Tout le code est à revoir si le projet doit évoluer.

Avec l'ORM on souhaite se rendre indépendant de la db mais au final on se retrouve lié aux contraintes de la librairie/framework utilisé.

J'ai tendance à penser qu'un framework est beaucoup plus "volatil" qu'une base de données ou qu'un langage. La question c'est : vaut-il mieux être lié à sa db ou son framework ORM ?

[wiztricks]

Salut,

La question c'est : vaut-il mieux être lié à sa db ou son framework ORM ?

Quels seraient les critères importants pour aller à droite plutôt qu'à gauche?

Dans mon job, j'essaie de distinguer les différents degré de stabilité des différentes entités qui devront être représentées dans le système technique.

La donnée persistante est en général plus stable que la représentation du monde vue par l'application. Cette stabilité relative mérite parfois qu'on construise un modèle de données privilégiant la pérennité des fonctions de persistance: plusieurs générations d'applications pourront en bénéficier.

A la périphérie du système technique, je privilégie la vitesse: ORM Active Record Patterns, langages scriptés tels que Ruby, PHP ou Python.

- W

[TekP@f]

Mais que font les modos !!!

Il y a déjà un post à ce sujet dans le bestof.
http://www.developpez.net/forums/d76...-performances/

Ca parle perf au départ mais le gros sujet, c'est bien la pertinence des ORM.

[dorian53]

Merci !

[wiztricks]

Mais que font les modos !!!

Il y a déjà un post à ce sujet dans le bestof.
http://www.developpez.net/forums/d76...-performances/

Ca parle perf au départ mais le gros sujet, c'est bien la pertinence des ORM.

J'aurais sans doute du citer le post, d'autant que je le suis.

En fait, le monde PHP est plutôt dans la périphérie du SI et pour lesquels les ORM ne peuvent qu'être que du bonheur s'ils sont utilisés avec modération comme le font RoR, Groovy, Django, Pylons,...

Dans le post cité, le champ de bataille est dans coeur du SI.
D'un côté les guerriers J2EE et leurs ORMs qui ne voient plus de limites dans leur emprise sur le coeur du SI...

De l'autre, la résistance menée par les tenants des SGDB-R (et ceux qui comme moi pensent qu'on fait aussi des choses bien avec les langages scriptés).

Parler à ces braves gens de langages scriptés, d'Active Records Pattern, de Rails,... de trucs "post-modernes" c'est prendre le risque de au mieux être ignoré au pire se retrouver dans les flammes d'un bucher.

- W
Architecte Post-Moderne

[Hephaistos007]

Dans le post cité, le champ de bataille est dans coeur du SI.D'un côté les guerriers J2EE et leurs ORMs qui ne voient plus de limites dans leur emprise sur le coeur du SI...

De l'autre, la résistance menée par les tenants des SGDB-R (et ceux qui comme moi pensent qu'on fait aussi des choses bien avec les langages scriptés).

Parler à ces braves gens de langages scriptés, d'Active Records Pattern, de Rails,... de trucs "post-modernes" c'est prendre le risque de au mieux être ignoré au pire se retrouver dans les flammes d'un bucher.

Normalement, il ne devrait y avoir que deux camps dans le débat : ceux pour l'ORM, et ceux contre. Par exemple, puisque vous prônez le pattern Active Records, vous êtes pour.
Que vient faire la notion de langage scripté vs compilé dans ce débat ? Que veut dire les tenants des "SGBD-R" ? sans SGBD-R il n'y a pas lieu de débattre de ORM...

[wiztricks]

Normalement, il ne devrait y avoir que deux camps dans le débat : ceux pour l'ORM, et ceux contre.
Par exemple, puisque vous prônez le pattern Active Records, vous êtes pour.

Je suis pragmatique.
Ce qui en la matière signifie d'utiliser la bonne techno pour faire dans l'enveloppe couts, délais, qualité de mes clients.

Que vient faire la notion de langage scripté vs compilé dans ce débat ? Que veut dire les tenants des "SGBD-R" ? sans SGBD-R il n'y a pas lieu de débattre de ORM...

Un ORM est une chose qui permet de mettre en relation des données de persistances - fichiers, enregistrements XML, ou autres avec des "classes" d'un langage objet -- pourquoi un SGDB-R???

Un SGDB-R est une solution quasi incontournable pour représenter de façon consistante une base de faits - mieux = Prolog, mais c'est un autre débat.
Si vous n'avez pas besoin de cette consistance, vous avez des solutions type KVP: CouchDB ou autres qui peuvent être plus performantes.

SGDB-R et J2EE s'affrontent dans le cœur du SI.
Et pendant ce temps là nos guerriers ne voient pas ce qui bougent dans la périphérie.... i.e les langages scriptés.

Soyez curieux! Soyez ouvert!
Allez voir ce que permettent de faire avec des ORMs tels que SQLAlchemy, Elixir, SQLSoup,...
Comparez avec Hibernate...

- W






- W