Discussion :

[Nighty]

Bonjour,

Actuellement j'étudie Doctrine 2 car je souhaite l'utiliser pour un projet complexe ayant besoin d'un ORM basé sur un Data Mapper.

J'aimerais recueillir les avis des utilisateurs de Doctrine 2 sur le choix du "Mapping Driver" car il y a un élément qui me gêne un peu.

Je vois un peu partout que le driver "Docblock Annotations" est très plébiscité : il est mis en avant dans la doc de Doctrine 2, et beaucoup de développeurs semblent ne jurer que par lui.

Pour ma part, il me pose quand même quelques problèmes...

Le premier, et le moindre, c'est qu'il a tendance à envahir un peu les commentaires. Une entité un peu conséquente risque de devenir difficilement lisible si chacune de ses nombreuses propriétés se voit "décorée" d'un gros bloc de commentaire en plus du docblock déjà existant.

Le second, qui à mon avis est beaucoup plus grave, est que j'y vois un début de couplage entre le modèle métier et la couche de données, ce qu'un Data Mapper est sensé éviter à l'origine.

On est d'accord, ce sont juste des commentaires, mais il n'empêche que l'on insère une logique de mapping à l'intérieur même des objets métiers. Si jamais plus tard on veut changer d'ORM, cela implique donc de retoucher les objets métiers, même si c'est juste sur le plan "esthétique".

L'avantage par contre c'est de limiter les "oublis" de mise à jour de la configuration du mapping, car il est plus facile d'oublier une modif dans un fichier extérieur.

Avant de risquer l'implosion face à tant de questions existentielles, je m'en remet à vos avis : quels sont vos retours d'expérience sur le sujet ? Que préférez-vous utiliser comme Mapping Driver en règle générale ?

[Nighty]

Je me permet un petit "up" du sujet, notamment pour apporter quelques éléments supplémentaires à mes interrogations.

Ayant lu la documentation de référence de Doctrine 2, je suis tombé sur la doc suivante, qui présente comment "mapper" les entités directement avec du code PHP, et donc sans passer par une syntaxe de configuration différente : http://www.doctrine-project.org/docs...p-mapping.html

Je trouve assez curieux que ce "driver" ne soit pas plus mis en avant que ça dans la documentation (il n'est même pas, le plus souvent, évoqué comme l'un des formats existants). Pourtant il semble que cette façon de faire ait plusieurs avantages :

- Déjà sur le plan des performances, même si avec les fonctionnalités de cache la différence devrait être minime, c'est théoriquement le plus performant des 4 car on s'affranchit du parsing de la configuration : elle est directement exécutée.

- Aussi sur le plan de l'adoption : avec PHP on est en terrain connu, on peut même bénéficier de l'autocomplétion avec l'IDE qui va bien. Du coup, on s'affranchit de l'apprentissage d'une syntaxe propre aux fichiers de configuration pour plutôt apprendre le modèle objet de Doctrine 2, ce qui est je trouve beaucoup plus bénéfique.

- Vu que tous les autres formats de configuration sont au final "traduits" en PHP, on est sûr qu'à aucun moment on ne soit limité par ce format.

La contrepartie, c'est qu'on risque de devoir changer les métadonnées de mapping si le modèle objet change.

Quelqu'un utilise-t-il PHP comme driver pour les métadonnées ? Est-ce aussi satisfaisant à l'utilisation que ça en a l'air "sur le papier" ?

[pc.bertineau]

Je pense que très peu de personnes utilisent PHP pour la config sous Sf2 :

• Comme tu le prédis, la différence de perf est réduite à un point négligeable grâce au caching,[/*]
• Les développeurs Symfony sont familiers du format YAML depuis Sf1, le format XML est bien maîtrisé par les développeurs Web (web services notamment), et les annotations tendent à devenir un standard. Et ces 3 formats sont plus courts que le PHP, donc plus lisible, plus facilement éditable => parfait pour de la configuration.[/*]

[gilwath]

Je pense qu'en production, peu importe le mapping driver, les performances sont les mêmes ( dut au cache ). Et je pense que le gain de performance en développement est minimes

[RapotOR]

Un autre point important est le nombre de ressources que l'ont peut trouver dans tel ou tel format.

Dans un gros projet encore plus qu'un autre, tu rencontreras sans aucun doute des cas plus sensibles pour lesquels des expériences te seront utiles, voire indispensables. A ce moment la, tu seras content d'avoir choisi le driver le plus répandu.

[Nighty]

Merci à tous pour vos réponses.

RapotOR tu marques un point : il fait rarement bon utiliser les solutions les moins répandues, soit parce qu'elles le sont à juste titre, soit parce qu'elles risquent à terme de se voir porter moins d'attention pour les prochaines évolutions (sans compter le besoin d'avoir des retours d'expérience comme tu le souligne).

La problématique de performance que j'évoque est triviale (quoi qu'il faudra quand même surveiller pour un projet qui évolue rapidement, et pour lequel on risque de vider le cache régulièrement), par contre la problématique de couplage (minime, mais couplage quand même) liée aux annotations est encore le principal frein qui me bloque pour adopter ce format.

Je vais réfléchir à nouveau à tout ça avant d'arrêter une décision, merci à vous

Edit : je marque la discussion résolue. Après réflexion, et m'être rendu compte que dans tous mes tests j'avais opté pour les annotations pour "aller plus vite", j'ai finalement opté pour ces annotations car elles sont vraiment plus élégantes et lisibles.