[PHP 5.3] Modélisation d'une relation 1 à plusieurs - Avantage ou non d'un ORM

**Benjamin Delespierre** · 11/02/2011, 11h23

Cette discussion est la suite du message [PHP 5.3] Modélisation d'une relation 1 à plusieurs.

Elle a été déplacée vu le hors sujet évident par rapport au sujet original.

Michel Rotta

Ce n'est que ce que j'ai décris plus haut.

Ouais bon ok, sans café Benjamin n'est pas très attentif...

C'est le projet de kyfr59. J'ai déjà ce qu'il me faut au niveau de mon modèle de données (DAO pour les gros projets, Model tout bête pour les petits).

J'ai pas pris Doctrine parce que j'avais pas le temps matériel de lire leur manuel de 300 page, mais c'est vrai que c'est un projet très intéressant.
Remarque, en ce moment je me sens de plus en plus attiré par les SGBD non-relationnels (Cassandra, MongoDb, Redis et leurs copains) qui offrent, à mon sens, beaucoup plus de flexibilité pour les applications web.

Bon en tout cas merci d'être venu corriger le tir, je crois que je partais dans la mauvaise direction...

**Michel Rotta** · 11/02/2011, 13h11

No problèmo.

Moi je me suis mis au thé, moins problématique le matin

Doctrine 2 embarque un driver pour MongoDB... ce qui permet de traiter, dans une même application, des données en mode relationnel et d'autre non et ce, d'une manière presque transparente côté contrôleur. Pas que j'ai particulièrement d'actions chez Doctrine, mais vu qu'on vit ensemble depuis deux ans, cela crée des liens.

**Benjamin Delespierre** · 11/02/2011, 14h05

Ah d'accord

Je suis en train de regarder du coté de Lithium pour le mécanisme de persistance, avec les Adaptaters et le Strategy couplés sur de la méta programmation, ça se manipule comme on veut. C'est bluffant d'ingéniosité. Actuellement, je suis davantage un apôtre du couple PDO/Stream Wrappers pour la couche de données, ça permet à moindre coût d'avoir un mécanisme générique. Mais j'ai encore du chemin à faire

Mais on s'écarte du topic de Départ.

**Michel Rotta** · 11/02/2011, 14h18

C'est sur...

La persistance fait partie de Doctrine 2. Les Adaptaters et le Strategy je ne vois pas trop de quoi il peut s'agir.

**Benjamin Delespierre** · 11/02/2011, 14h31

Je parle des design pattern Adapter et Strategy. En tirant parti des nouveautés du langage (late static binding, closures, iterators, SPL etc.) une partie de la team de Cake PHP à fait bande à part pour créer Lithium (AKA Cake PHP 3).

Adapter est un design pattern mieux connu sous le nom de Wrapper. Il permet de faire communiquer entre elles des classes ne possédant pas les mêmes interfaces. Strategy quant à lui est un design pattern permettant de décider au runtime des traitements à effectuer (et avec les closures, on peut même les définir au runtime). Quand on mélange tout ça avec de la méta-programmation, on obtient une structure terriblement flexible (je suis passé d'une base de données MySQL à une base de données MongoDB en changeant d'adapter dans le fichier de conf). Mais c'est bien la moindre des choses que ce framework fait...
Le seul inconvénient est le manque de documentation (tout est très bien documenté dans le code lui même ou dans le wiki mais il n'y a aucun tuto pour se faire les dents avec ce super joujou).

**Michel Rotta** · 11/02/2011, 15h04

Ce sont des paternes que je n'utilise pas, d'où ma méconnaissance.

Pour framework je travail avec Symfony, la version béta 2 depuis 3 semaines. A fond développée pour le travail avec PHP 5.3.3 et les namespace se qui offre une grande souplesse en terme de développement. La communication entre objets "hétéroclite" passant par un système d'"Event Dispatcher" ma fois très efficace. Je ne sais pas si cela peut être comparé.

Une belle bête où l'on attend aussi un peu plus que de la simple documentation technique. Et qui inclus Doctrine (entre autre) d'où ma vision parcellaire de l'accès aux données.

**Benjamin Delespierre** · 11/02/2011, 15h37

Event dispatcher c'est le pattern Observer (SplObserver et SplListener sont là pour ça

).
Note qu'en PHP il n'existe pas de 'véritable' notion d'évènement: chaque évènement doit parcourir tout son flow avant de rendre la main au processus en cours. Je manque de connaissances pour affirmer que ce n'est pas le cas dans des langages comme Java...

Je ne pense pas que ce soit la même chose. Adapter c'est exactement comme un adaptateur pour une prise électrique britannique par exemple, c'est une classe que tu mets entre deux interfaces et qui assure la transition/transformation de tes données.

Si tu veux de la doc sur les principaux designs patterns (GRASP) y'a la référence en la matière ici : http://martinfowler.com/eaaCatalog/
Son livre c'est "Design Patterns in enterprise architecture" ou un truc du genre...

Est-ce que Symphony intègre toujours le support de Propel ou ils l'ont finalement abandonné ?

**Michel Rotta** · 11/02/2011, 16h06

Actuellement Symfony 2 n'intègre que Doctrine.

Vu le fonctionnement très souple, on doit pouvoir facilement intégrer un autre ORM. Et s'il est proche de Doctrine en terme de fonctionnalité, le passage de l'un à l'autre pourrait être presque transparent. Je n'ai rien vu sur le blog dev de Symfony 2 sur une prochaine intégration ou un abandon de propel.

Je connais le bouquin "Design Patterns in ..." pour l'instant ce qui me manque le plus c'est des journées de 48H pour tous suivre et faire !

Il faudra que je jette un œil sur Adapter. Quoique, en restant dans le moule confortable d'un framework comme Symfony, il y ait peu de chance que j'ai un jour à l'utiliser.

**Benjamin Delespierre** · 11/02/2011, 16h31

En effet, mais je n'utilise pas ce que je ne peux pas comprendre (ouais, bon, je suis légèrement maniaque).

Je n'ai jamais eu à utiliser Doctrine ou Propel mais d'après leurs documentations respectives, il semble faire la même chose mais avec 2 approche très différentes.

Un ORM maison, des Iterateur, du Lazy Loading, un peu d'Active Record et le tour est joué

**Michel Rotta** · 11/02/2011, 18h45

Je n'ai plus travaillé sous propel depuis plus de deux ans je ne vais donc pas pouvoir discuter de ces mérites.

Par contre, je pense que tu es un peu limitatif pour réduire le travail d'une équipe de plusieurs dizaine de développeur et une documentation conséquente quant tu dis : "des Iterateur, du Lazy Loading, un peu d'Active Record et le tour est joué" pour résumer Doctrine.

C'est enterrer un peu vite :

la possibilité de changer de moteur de donnée d'une manière transparente, tu développes en SQLite, tu exploites en Oracle.
la persistance des données
l'utilisation transparente des données dans un modèle objet PHP 5.3
un langage d'interrogation propre, le DQL qui permet de s'assurer de l'indépendance de la couche donnée
Notion d'héritage de classe et/ou de table pour leur définitions
gestion implicite et explicite des transactions

Plus la sécurité d'accès aux données et à la construction de requêtes.

Je doute que quelques lignes de PHP, aussi géniales soient-elles puisses offrir un tel sécurité et un tel confort d'utilisation.

**Benjamin Delespierre** · 12/02/2011, 11h39

J'ai pas la prétention d'avoir créé un mécanisme aussi puissant que Doctrine évidement

**Michel Rotta** · 12/02/2011, 12h26

Mais si je comprend bien, tu adaptes ton système pour chaque application/site que tu crées ?

Comment assures-tu la maintenance si un jour, dans tes méthodes, tu découvre une faiblesse ou un bug ? Comment retrouver sur quel application/site tu as un code identique ou suffisamment semblable pour risquer d'être impacté ?

**Benjamin Delespierre** · 13/02/2011, 21h23

Parce que les éléments de base sont sous SVN. Je peux identifier la branche de support concernée et tous les tags émis à ce jour et produire un patch en un rien de temps.
Et je n'adapte pas le système à chaque site créé, j'étends les classes de base.

Par ailleurs, je peux en dire autant de l'utilisation d'un ORM comme doctrine. Si demain ça ne marche plus correctement avec la version de MySQL qui vient d'être mise à jour, tu fais quoi ? il faut que tu comptes sur les gens qui maintiennent Doctrine. Si ça te fais perdre de l'argent, vers qui tu te retournes ?
L'avantage de créer ses propres solution c'est d'avoir un contrôle total sur sa solution et en cas de souci, de pouvoir les mettre à jour.

**Michel Rotta** · 14/02/2011, 16h29

Et je n'adapte pas le système à chaque site créé, j'étends les classes de base

Tu es mure pour utiliser un ORM

Par ailleurs, je peux en dire autant de l'utilisation d'un ORM comme doctrine. Si demain ça ne marche plus correctement avec la version de MySQL qui vient d'être mise à jour, tu fais quoi ? il faut que tu comptes sur les gens qui maintiennent Doctrine. Si ça te fais perdre de l'argent, vers qui tu te retournes ?
L'avantage de créer ses propres solution c'est d'avoir un contrôle total sur sa solution et en cas de souci, de pouvoir les mettre à jour.

J'espère que te n'imagine pas réellement ce que tu dis là.
A ton avis, combien de personnes travaillent aujourd'hui avec Doctrine ? Tu crois vraiment qu'un projet de cet envergure va être mis en arrêt par un changement dans MySql ? Tu peux être sur qu'Oracle sera en contact bien avant la sortie, voir même, va dépêcher ces propres ingénieurs pour qu'un tel outil soit parfaitement compatible. Dans tous les cas, la communication se fait par DBO avec la base. Et je vois mal Zend se faire griller sur une intégration de la base de données.

Accessoirement, combien de sites en production as-tu migré le jour de la sortie d'une nouvelle version de la base de donnée vers celle-ci ? Moi, je connais ma réponse...

**Benjamin Delespierre** · 14/02/2011, 16h53

Je sais, je cherche la petite bête

J'ai eu le même problème dans ma boite quand j'ai demandé d'utiliser PHP 5.3 au lieu de 5.1 (actuellement la version la plus à jour supportée par RedHat). Je remets ici les arguments qu'on m'a sorti en défaveur de la migration vers 5.3.
Cela étant, c'est une problématique véridique dans le milieu industriel.

Bon, et qu'on soit bien d'accord. Je suis carrément pour l'utilisation d'un ORM. C'est juste que j'ai tellement ~~la flemme~~ pas le temps d'apprendre à l'utiliser...

Tiens pendant que t'es là, tu aurais des comparatifs de performances pour les différents ORM et leurs fonctionnalités par rapport à leur équivalent PDO ou mysqli ??

**Michel Rotta** · 15/02/2011, 09h48

Non, je n'ai pas ça sous la main.

Et honnêtement, je n'en vois pas trop l'intérêt. En effet, les performance de Doctrine ne peuvent être meilleur que celle de PDO, sur lequel il s'appuie pour la couche d'accès aux données.

Ensuite utiliser mysqli alors qu'il y a en standard dans PHP du PDO relève presque d'une faute professionnel... (sauf à reprendre du code d'une vielle application qui tournerait encore pour des raisons de portabilité en PHP4.

Et que comparer ? Pour que l'on puisse comparer les performances il faudrait le faire à niveau de programmation égale et niveau de sécurité comparable. Hors Doctrine ne sais pas faire les choses simplement...

Par curiosité j'ai lancé google à la chasse et il m'a ramené un benchmark réalisé par doctrine (est-ce réaliste) entre PDO, propel et plusieurs configurations de Doctrine. On peu voir que dans la configuration idéal, Doctrine 2 s'en sort presque aussi vite que PDO.

Il reste que illusoirement, l'utilisation d'un ORM à un impacte négatif sur le temps d'accès aux données. Illusoirement, parce que l'ORM fait faire une bonne partie du code que tu devras faire directement si tu ne l'utilise pas. Et si tu prends ce code en compte...

Et que tu vas devoir passer une partie non négligeable de ton temps à développer une couche d'ORM "maison" qu'il faudra bien impacter dans le temps de développement des projet, mais ça, c'est une autre histoire.

**Benjamin Delespierre** · 15/02/2011, 10h57

Ensuite utiliser mysqli alors qu'il y a en standard dans PHP du PDO relève presque d'une faute professionnel.

Et comment. C'est dingue qu'il y ait autant de demandes d'aide sur le forum pour mysql et mysqli mais ~~jamais~~ rarement pour PDO...

Et que tu vas devoir passer une partie non négligeable de ton temps à développer une couche d'ORM "maison" qu'il faudra bien impacter dans le temps de développement des projet, mais ça, c'est une autre histoire.

C'est vrai... Je vais aller me flageller avec des orties ce soir

Je ne sais pas si tu sais mais le soft de design de MySQL, MySQL Workbench (anciennement dbDesigner4) possède un plugin pour créer des YAML pour doctrine à partir d'un shéma relationnel: http://code.google.com/p/mysql-workb...ctrine-plugin/

**Michel Rotta** · 15/02/2011, 11h47

Envoyé par Benjamin Delespierre

Et comment. C'est dingue qu'il y ait autant de demandes d'aide sur le forum pour mysql et mysqli mais ~~jamais~~ rarement pour PDO...

Je pense que c'est dû au bouquin dans le commerce, cherches-en un sur le développement de site avec PHP, MySql et PDO et tu ne risques pas de dépenser des milles et des cents.

Envoyé par Benjamin Delespierre

C'est vrai... Je vais aller me flageller avec des orties ce soir

Mmmm une note SM maintenant ?

j'ai déjà les gants

Envoyé par Benjamin Delespierre

Je ne sais pas si tu sais mais le soft de design de MySQL, MySQL Workbench (anciennement dbDesigner4) possède un plugin pour créer des YAML pour doctrine à partir d'un shéma relationnel: http://code.google.com/p/mysql-workb...ctrine-plugin/

Oui, j'ai utilisé longtemps. Le seul plugin qui fasse un code yaml qui me convienne presque. Sauf qu'il ne fait le code que pour Doctrine 1 et que je suis passé à doctrine 2.

Le problème est que le code yaml et le code objet d'aujourd'hui va plus loin que la simple transposition du schéma d'une base. Soit l'outil de génération du MPD n'est pas suffisamment en phase avec l'ORM. Soit il manque une couche entre la génération des champs à partir du MPD qui permette d'ajuster la partie objet du schéma nécessaire à la création de tes objets Doctrine.

**Benjamin Delespierre** · 15/02/2011, 13h46

Le problème est que le code yaml et le code objet d'aujourd'hui va plus loin que la simple transposition du schéma d'une base. Soit l'outil de génération du MPD n'est pas suffisamment en phase avec l'ORM. Soit il manque une couche entre la génération des champs à partir du MPD qui permette d'ajuster la partie objet du schéma nécessaire à la création de tes objets Doctrine.

Ok j'y penserai.

Est-ce qu'au passage il existe des libraires de génération / validation de formulaires capables de s'interfacer avec Doctrine ?