ORM PHP: Doctrine vs Propel


126

Je démarre un nouveau projet avec symfony qui est facilement intégré à Doctrine et Propel , mais je dois bien sûr faire un choix .... Je me demandais si les gens plus expérimentés avaient des avantages et / ou des inconvénients généraux pour y aller. l'un de ces deux?

Merci beaucoup.

EDIT: Merci pour toutes les réponses, des trucs utiles. Il n'y a pas de réponse vraiment correcte à cette question, je vais donc simplement marquer comme approuvée celle qui a obtenu les votes les plus populaires.


5
Les gars, y a-t-il des réponses mises à jour? Voyant que cette façon
n'est plus à

Réponses:


76

J'irais avec Doctrine. Il me semble que c'est un projet beaucoup plus actif et étant l'ORM par défaut de symfony, il est mieux supporté (même si officiellement les ORM sont considérés comme égaux).

De plus, j'aime mieux la façon dont vous travaillez avec les requêtes (DQL au lieu de Criteria):

<?php
// Propel
$c = new Criteria();
$c->add(ExamplePeer::ID, 20);
$items = ExamplePeer::doSelectJoinFoobar($c);

// Doctrine
$items = Doctrine_Query::create()
       ->from('Example e')
       ->leftJoin('e.Foobar')
       ->where('e.id = ?', 20)
       ->execute();
?>

(La mise en œuvre de Doctrine est beaucoup plus intuitive pour moi).

De plus, je préfère vraiment la façon dont vous gérez les relations dans Doctrine.

Je pense que cette page de la documentation Doctrine vaut la peine d'être lue: http://www.doctrine-project.org/documentation/manual/1_2/en/introduction:doctrine-explained

Pour résumer: si je commençais un nouveau projet ou si je devais choisir entre apprendre Doctrine et Propel, j'irais pour Doctrine n'importe quel jour.


42
Dans Propel 1.5, cette requête peut également être écrite comme Example_Query :: create () -> joinWith ('FooBar') -> filterId (20) -> find () (ou findPK (20) après le joinWith si Id est votre principal clé). Comme vous pouvez le voir, il reprend la belle syntaxe de Doctrine et en ajoute un peu plus. La sortie est prévue pour la fin du premier trimestre 2010, mais vous pouvez la tester maintenant dans vos projets Symfony.
Jan Fabry


9
la mise en œuvre de la doctrine me semble beaucoup plus complexe. Get Entity manage get repository ... this and that
SoWhat

1
la doctrine est sur la complication des choses ... juste notorm est la voie à suivre
Geomorillo

40

Je suis partial, car j'aide un peu sur la prochaine version de Propel, mais vous devez considérer que Propel était en effet le premier ORM disponible, puis a un peu pris du retard lorsque Doctrine a été créée, mais a maintenant à nouveau un développement actif. Symfony 1.3 / 1.4 est livré avec Propel 1.4, où la plupart des comparaisons s'arrêtent à Propel 1.3. De plus, la prochaine version de Propel (1.5) contiendra de nombreuses améliorations, en particulier dans la création de vos critères (résultant en moins de code à écrire).

J'aime Propel car il semble moins complexe que Doctrine: la plupart du code se trouve dans les quelques classes générées, alors que Doctrine a divisé les fonctionnalités en de nombreuses classes. J'aime bien comprendre les bibliothèques que j'utilise (pas trop de "magie"), mais bien sûr, j'ai plus d'expérience avec Propel, alors peut-être que Doctrine n'est pas si compliquée en coulisses. Certains disent que Propel est plus rapide, mais vous devriez vérifier cela par vous-même et déterminer si cela l'emporte sur d'autres différences.

Peut-être devriez-vous également considérer la disponibilité des plugins Symfony pour les différents frameworks. Je pense que Propel a un avantage ici, mais je ne sais pas combien de plugins listés sont encore à jour avec la dernière version de Symfony.


4
Les nouvelles améliorations apportées aux requêtes dans Propel 1.5 sont vraiment intéressantes.
Tom

23

Cela dépend de vos préférences personnelles. J'utilise Propel parce que (entre autres) j'aime le fait que tout a sa propre méthode getter & setter concrète. Dans Doctrine, ce n'est pas le cas.

Propulser:

$person->setName('Derek');
echo $person->getName();

Doctrine:

$person->name = 'Derek';
echo $person->name;

La raison pour laquelle j'aime avoir des getters et des setters, c'est que je peux y mettre toutes sortes de logiques, si j'en ai besoin. Mais c'est juste ma préférence personnelle.

Je dois également ajouter que bien que Propel ait évolué lentement dans le passé, il est à nouveau en développement actif. Il a publié plusieurs nouvelles versions au cours des derniers mois. La version la plus récente de Propel inclut une "interface de requête fluide" similaire à celle de Doctrine , vous n'avez donc plus besoin d'utiliser Criteria si vous ne le souhaitez pas.


7
dans Doctrine, vous pouvez remplacer les setters et les getters pour chaque propriété et également avoir une logique personnalisée (voir doctrine-project.org/documentation/manual/1_2/en/… - recherchez ATTR_AUTO_ACCESSOR_OVERRIDE pour accéder à la section appropriée)
Marek Karbarz

Cela semble correct, mais vous définissez toujours la propriété en appelant: $ x-> propname = 'abc'; Ceci est problématique car il ne semble pas prendre en charge le passage de plusieurs paramètres.
lo_fye

20

Il convient de noter que Doctrine 2 est actuellement en développement publié [ed] et fonctionne presque complètement différent de la version stable actuelle de Doctrine 1. Il repose sur le modèle Data Mapper au lieu d'Active Record, et utilise un «gestionnaire d'entités» pour gérer la persistance logique. Une fois publié, il ressemblera plus à Hibernate de Java (Doctrine 1 ressemble plus à ActiveRecord de Rails).

J'ai développé avec la version alpha de Doctrine 2, et je dois dire que c'est tête et épaules au-dessus de Doctrine 1 (juste mon avis, et je n'ai jamais utilisé Propel). Il y a de bonnes chances que la communauté Doctrine se dirige vers elle une fois qu'elle sera publiée.

Je vous encourage à consulter Doctrine, mais si vous préférez le style Active Record que Propel et Doctrine utilisent maintenant, vous voudrez peut-être vous en tenir à Propel.


4
Une version stable de Doctrine 2 a récemment été publiée. doctrine-project.org/blog/doctrine2-released
Trevor Allred

5

Les deux références sont quelque peu obsolètes, donc vous couvrez néanmoins quelques généralités, en gros vous devrez évaluer votre expérience avec le framework en tant que tel, un inconvénient majeur de la doctrine est l'incapacité d'avoir un IDE qui vous permet de coder automatiquement dans cette propulsion. un gagnant, les courbes d'apprentissage propulsent et la doctrine sont très différentes, il est plus facile de propulser, si votre projet aura besoin de gérer un modèle de données complexe utilise la doctrine, si vous voulez travailler rapidement avec un ORM qui est mieux documenté et trouver plus de support dans Propel Internet utilise, est beaucoup plus mature et je pense que le plus utilisé.

http://propel.posterous.com/propel-141-is-out


Dans le monde de symfony, il semble que Doctrine soit définitivement la plus utilisée - en particulier pour les projets plus récents. Il y a bien sûr beaucoup de projets sf 1.0 qui utilisent encore Propel car Doctrine n'était pas disponible pour symfony avant la version 1.1.
phidah

5

Je suggérerais d'utiliser propel 1.6, ce qui est meilleur pour la fonction de saisie semi-automatique de l'IDE.


26
-1 L'auto-complétion d'un IDE ne devrait pas être la raison d'un choix technique
Clement Herreman

14
@ClementHerreman Je suis d'accord que cela ne devrait pas être le critère, mais je pense que la productivité d'une technologie particulière devrait certainement être une raison pour la choisir. Et avec tout le respect que je vous dois, je ne suis donc pas d'accord avec votre vote défavorable ... que vous soyez d'accord ou non avec la réponse, ce n'est pas «faux» (ou est-ce?), Et c'est d'une certaine utilité (sauf si c'est faux, auquel cas , vous devriez le dire).
Sepster

2
IMO si votre productivité est plus améliorée par l'auto-complétion au lieu de la qualité du logiciel, de l'intuitivité et de la cohérence, alors quelque chose de bizarre se produit. Voir codinghorror.com/blog/2009/01/… . Mais vous avez raison, à un moment donné, cette réponse n'est pas fausse , juste pas assez bonne, peut-être même pas bonne.
Clement Herreman le

1
@ClementHerreman, si cela n'est pas utile, ne l'utilisez plus;), +1
amd

Y a-t-il des réponses à jour à ce sujet? C'est bien dépassé.
Qiniso

2

Je ne suis pas un utilisateur de PHP 5 non-framework ORM, mais voici quelques bons articles de comparaison (au cas où vous ne les auriez pas encore vus):

http://codeutopia.net/blog/2009/05/16/doctrine-vs-propel-2009-update/

http://trac.symfony-project.org/wiki/ComparingPropelAndDoctrine

Les deux conlusion favorisent Doctrine en tant que nouvelle génération d'ORM pour Symfony.


1
Pour mémoire, cette comparaison est totalement obsolète - la version actuelle de Propel utilise PDO, prend en charge les relations plusieurs-à-plusieurs et dispose d'une excellente documentation. À considérer également: certains d'entre nous préfèrent le style de requête verbeux du générateur de critères aux langages de requête propriétaires comme DQL - il prend en charge l'IDE, et c'est une classe, vous pouvez donc l'étendre. J'essaie toujours de choisir, mais je vois beaucoup d'avantages pour Propel par rapport à Doctrine, si cela ne vous dérange pas de générer du code statique et que vous pouvez voir les avantages du "vrai" code PHP par rapport au langage de requête propriétaire , qui ne sont que des chaînes vers un IDE.
mindplay.dk

2

Après avoir utilisé les deux pendant un certain nombre d'années, je préfère Propel 2 à Doctrine simplement en fonction de la façon dont vous construisez votre logique de requête. La doctrine est aussi approfondie que possible et la gestion de nombreux aspects correspond à ce niveau de profondeur. Je pense que Propel a une manière plus fluide et orientée objet de créer et de gérer les interactions de requête.

Pour moi, cela a conduit à moins de code dans le modèle et plus de structures autour de la façon dont la logique peut / sera traitée. Cela a abouti à la création de nombreuses interactions en tant que fonctionnalité commune. (Après tout, 90% de ce que vous ferez avec une base de données sera juste un certain degré d'opération grossière.)

En fin de compte, les deux sont puissants, gérables et feront le travail. Mes projets personnels et mes intérêts utilisent Propel ORM 2 et les projets futurs, s'ils sont toujours écrits en PHP, suivront cette voie.

J'utilise les deux au quotidien depuis 3-4 ans.


1

Je suggérerais d'utiliser DbFinder Plugin . Il s'agit en fait d'un plugin très puissant qui prend en charge les deux et qui est assez puissant. J'aime mieux l'utiliser que l'un ou l'autre.


@Mike: merci, je ne connaissais pas le plugin mais il semble qu'il ne supporte que jusqu'à Sf1.2. J'ai fini par utiliser Doctrine à la fin, j'ai l'impression que c'était le bon choix, bien que l'écriture directe de SQL soit nécessaire pour les choses plus complexes.
Tom

-2

Si je ne me trompe pas, les deux ORM utilisent un schéma XML et la création de ces définitions de schéma est assez fastidieuse. Si vous avez besoin d'un schéma simple basé sur PHP avec un style fluide. Vous pouvez essayer LazyRecord https://github.com/c9s/LazyRecord, il prend en charge la migration automatique et les générateurs de scripts de mise à niveau / rétrogradation. Et tous les fichiers de classe sont générés statiquement sans coût d'exécution.

En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.