Discussion :

[octal]

Bonjour,
je voulais avoir votre avis concernant l'utilisation de DOCTRINE ou PROPEL dans une application Symfony.
Avez vous déjà fais cela? est ce que Doctrine/Propel est utilisable de manière professionnelle sans trop de contraintes?
ou est ce qu'il est plus simple de rester sur une implémentation utilisant directement du SQL classique (en modélisant correctement les données bien sûr).

Tout retour d'expérience serait le bienvenu.

[Tsilefy]

Je n'ai plus utilisé Propel depuis Propel 1 donc je ne peux pas te dire grand-chose sur le Propel d'aujourd'hui; mais tu trouveras largement plus de documentation et de solutions à tes problèmes sur le net avec Doctrine qu'avec Propel, tout simplement parce que la communauté Doctrine est plus grande.

Doctrine est en fait composé de 2 librairies: Doctrine DBAL et Doctrine ORM. Avec DBAL, tu manipules toujours du SQL classique, avec ou sans query builder. Pour simplifier, c'est une interface orientée objet autour de PDO, en mieux pensé. Je dirais que si tu écrit des requêtes directement, il n'y a pas de grandes différences entre PDO et DBAL. Mais doctrine a les query builders, et d'expérience dès qu'on se lance dans des requêtes un peu compliquées, i.e. non statiques, on finit toujours par construire un query builder maison, et dans ce cas autant en choisir un testé et éprouvé.

L'ORM est différent. Et tout dépend de tes besoins. Est-ce que tu as besoin de mapper tes données en objets? Si tu travailles essentiellement sur des agrégats ou sur du reporting par exemple, SQL direct est beaucoup mieux. Si ton application est déjà en DDD, un ORM est justifié. Un ORM implique forcément une baisse de performance, à toi de savoir si cette baisse est acceptable ou pas (d'expérience, oui, elle l'est dans la majorité des cas). Et qand tu as vraiment besoin de perf, Doctrine te permet toujours de revenir à du SQL natif pour tout ou partie du code.

La seule contrainte est évidemment la courbe d'apprentissage. Mais là encore tout dépend du niveau de tes dév, de leurs expériences.... Propel, qui est un Active Record, devrait être plus facile à aborder que Doctrine (Data Mapper); mais dès que tu te heurteras à des problèmes un peu avancés, tu trouveras plus de réponses pour Doctrine ici ou sur Stack Overflow que sur Propel. Et Active Record a des problèmes qui méritent un article entier.

L'erreur habituelle lorsqu'on utilise un ORM est de croire qu'on peut s'affranchir entièrement de penser à la base de données. Une excellente connaissance de SQL et la bdd est nécessaire pour pouvoir bien l'exploiter.

Et je viens de voir que Propel2 n'est plus maintenu et qu'avec Propel 3 ils abandonnent Active Record pour utiliser le pattern Data Mapper comme Doctrine. Sauf que Propel 3 est encore en développement. Donc je pense que ça élimine Propel pour l'instant.

[octal]

Merci Tsilefy pour cette réponse très détaillée.
Je ne savais pas que Propel2 était à l’abandon

Pour moi, honnêtement j'hésite à utiliser un ORM pour deux raisons:
1- la complexité de l'usage dès qu'il s'agit de relations à 2 ou 3 niveaux.
2- le fait que le datamapper ainsi que l'active-record soient tous les deux complètement anti-pattern, (entre accès directe aux données privées de l'objet et mêler les responsabilités et le domaine de données de l'app vs données de stockage... bref).
De toutes les façons, le problème survient à chaque fois que l'on veut modéliser des données de bases de données NON-objets vers un modèle métier complètement OO.

Bref,
j'ai cherché un peu dans la nature et j'ai trouvé aussi SPOT qui me semble bien plus simple, mais encore une fois, c'est le support qui pose problème quand on utilise un outil une application. Sur du Doctrine pure, il semble qu'il y ait une communauté bien active.

Personnellement je bosse sur une application assez simple ces jours-ci, utilisant une BDD d'une dizaine de tables seulement et manipulant une 40-aines d'objets métiers, dont environ le quart doit être persisté. Un ORM ne me poserai pas de pb concernant la vitesse, je n'ai besoin que de requêtes assez simple (simple jointures dans le pire des cas), et la plus volumineuse de mes tables n'aura pas plus de 200.000 enregistrements environ.
Pour une application web de moins de 15 pages, je pense que le couple Symfony/Doctrine fera largement l'affaire.

Maintenant pour revenir sur le problème de l'abstraction de la BDD, c'est au contraire, à ce niveau là que l'ORM me pose problème. Je pense que Doctrine cache ennormément la BDD et cela me pose problème en ce sens que je sens que je perds le contrôle. Je suis plus habitué à écrire du pure et dure SQL.