PHP ORM: Doctrine vs. Propel

Question

Je commence un nouveau projet avec symfony qui est facilement intégré avec la Doctrine et Propel, mais j'en ai besoin pour faire un choix.... Je me demandais si le plus connu des gens là-bas ont en général des avantages et/ou inconvénients pour aller avec un de ces deux?

Merci beaucoup.

EDIT: Merci pour toutes les réponses, des trucs utiles. Il n'y a pas vraiment de bonne réponse à cette question, donc je vais marquer comme approuvé celui qui a obtenu le plus populaire jusqu'-voix.

Answer 1

J'irais avec la Doctrine. Il me semble qu'il est beaucoup plus actif en projet et en cours de l'ORM par défaut de symfony c'est mieux pris en charge (même si, officiellement, les Formulaires sont considérées comme égales).

De plus, j'ai mieux aimé la façon dont vous travaillez avec les requêtes DQL au lieu de Critères):

<?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();
?>

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

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

Je pense que cette page de la Doctrine de la documentation est intéressant à lire: http://www.doctrine-project.org/documentation/manual/1_2/en/introduction:doctrine-explained

Pour résumer: Si je ont été de commencer un nouveau projet ou avait à choisir entre l'apprentissage de la Doctrine et Propel j'irais pour la Doctrine de tous les jours.

Answer 2

Je suis partial, depuis que je l'aide un peu sur la prochaine version de Propulser, mais vous devez considérer que Propel était en effet le premier ORM disponibles, puis à la traîne un peu lors de la Doctrine a été créé, mais maintenant actif dans le développement de nouveau. Symfony 1.3/1.4 est livré avec Propel 1.4, où la plupart des comparaisons s'arrêtent à Propel 1.3. Aussi, la prochaine version de Propulser (1.5) contient un grand nombre d'améliorations, notamment dans la création de vos Critères (résultant en moins de code pour vous écrire).

J'aime Propulser parce qu'il semble être moins complexe que de la Doctrine: la plupart du code est dans les quelques classes générées, alors que la Doctrine a divisé la fonctionnalité dans beaucoup de classes. J'aime avoir une bonne compréhension des bibliothèques que j'utilise (pas trop "magique"), mais bien sûr, j'ai plus d'expérience avec Propel, alors peut-être que la Doctrine n'est pas si compliqué derrière les coulisses. Certains disent que Propel est plus rapide, mais vous devriez vérifier par vous-même, et juger si cette emportent sur d'autres différences.

Peut-être vous devriez également tenir compte de la disponibilité des plugins Symfony pour les différents cadres. Je crois Propulser a un avantage ici, mais je ne sais pas combien de la liste des plugins sont toujours à jour avec la dernière version de Symfony.

Answer 3

Il se résume à la préférence personnelle. J'utilise Propulser parce que (entre autres choses) j'aime le fait que tout soit à sa propre béton getter et le setter de la méthode. Dans la Doctrine, ce n'est pas le cas.

Propel:

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

Doctrine:

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

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

Je dois également ajouter que, bien que de Propulser se déplaçait lentement dans le passé, il est maintenant en cours de développement, de nouveau. Il a publié plusieurs nouvelles versions dans le passé quelques mois. La version la plus récente de Propulser comprend un "fluent interface de requête" semblable à la Doctrine de la foi, de sorte que vous n'avez pas à utiliser des Critères plus si vous ne voulez pas.

Answer 4

Il convient de noter Doctrine 2 est actuellement en développement a publié [ed] et des fonctions presque complètement différente de la version stable actuelle de la Doctrine 1. Il s'appuie sur le motif de Mapper des Données au lieu de l'Enregistrement Actif, et utilise un entity manager " pour gérer la persistance de la logique. Lorsqu'il est libéré, il portera plus grande ressemblance avec Java Hibernate (Doctrine 1 est plus comme des Rails' ActiveRecord).

J'ai mis au point avec la version alpha de Doctrine 2, et il faut dire qu'il est la tête et les épaules au-dessus de la Doctrine 1 (juste mon avis, et je n'ai jamais utilisé Propel). Les Chances sont bonnes que la Doctrine de la communauté adoptera lorsqu'il est relâché.

Je vous encourage à consulter la Doctrine, mais si vous préférez l'Enregistrement Actif style de Propel et Doctrine utiliser maintenant, vous pouvez simplement coller avec Propel.

Answer 5

Les deux références sont un peu désuètes de sorte que vous néanmoins de couvrir une partie des généralités, fondamentalement, vous devez évaluer votre expérience avec le cadre en tant que tel, un inconvénient majeur de la doctrine est l'incapacité d'avoir une IDE qui vous permet de vous auto-code que propel est un gagnant, les courbes d'apprentissage propel et doctrine sont très différents, il est plus facile de propulser, si votre projet a besoin de gérer des données complexes modèle utilise doctrine, si vous souhaitez travailler rapidement avec un ORM qui est le mieux documenté et trouver plus de soutien à Propulser des usages de l'Internet, est beaucoup plus mature et je crois que les plus utilisés.

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