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

Citation:

---

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

---

Citation:

---

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

---

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

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...

No problèmo.

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

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. :lol:

Ah d'accord :P

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 :ccool:

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

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.

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).

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.

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é ?

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.

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é ;)

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.

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

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é ?

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.

Citation:

---

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

---

Tu es mure pour utiliser un ORM

Citation:

---

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.

---

:lol: 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...

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 ??

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.

Citation:

---

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...

Citation:

---

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/

Citation:

---

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.

Citation:

---

Envoyé par Benjamin Delespierre

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

---

Mmmm une note SM maintenant ? :sm: j'ai déjà les gants :mouarf:

Citation:

---

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.

Citation:

---

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 ?

Ma réponse va être partial.

Oui, celle de symfony.

• symfony 1.4 pour Doctrine 1.2
• Symfony 2.0 pour Doctrine 2

Mais il en existe peut-être d'autres...