Dois-je choisir Doctrine 2 ou Propel 1.5 / 1.6, et pourquoi? [fermé]

30

J'aimerais entendre ceux qui ont utilisé Doctrine 2 (ou version ultérieure) et Propel 1.5 (ou version ultérieure). La plupart des comparaisons entre ces deux mappeurs relationnels d'objets sont basées sur d'anciennes versions - Doctrine 1 contre Propel 1.3 / 1.4, et les deux ORM ont subi des remaniements importants dans leurs révisions récentes. Par exemple, la plupart des critiques de Propel semblent se concentrer sur les classes "ModelName Peer ", qui sont en tout cas obsolètes en 1.5.

Voici ce que j'ai accumulé jusqu'à présent (et j'ai essayé de rendre cette liste aussi équilibrée que possible ...):

  • Propulser
    • Avantages
      • Extrêmement convivial IDE, car le code réel est généré, au lieu de s'appuyer sur des méthodes magiques PHP. Cela signifie que les fonctionnalités IDE telles que la complétion de code sont réellement utiles.
      • Rapide (en termes d'utilisation de la base de données - aucune introspection d'exécution n'est effectuée sur la base de données)
      • Migration propre entre les versions de schéma (au moins dans la version bêta 1.6)
      • Peut générer des modèles PHP 5.3 (c'est-à-dire des espaces de noms)
      • Facile à enchaîner beaucoup de choses en une seule requête de base de données avec des choses comme des useXxxméthodes. (Voir la vidéo "Achèvement du code" ci-dessus)
    • Les inconvénients
      • Nécessite une étape de construction supplémentaire, à savoir la construction des classes de modèles.
      • Le code généré doit être reconstruit chaque fois que la version de Propel est modifiée, un paramètre est modifié ou le schéma change. Cela peut ne pas être intuitif pour certains et les méthodes personnalisées appliquées au modèle sont perdues. (Je pense?) - Pas vrai; les méthodes personnalisées ne sont pas perdues car la classe générée est une classe de base; Propel fournit une classe d'entité spécifiquement pour l'extension.
      • Certaines fonctionnalités utiles (comportement de version, migrations de schéma) sont en version bêta.
  • Doctrine
    • Avantages
      • Plus populaire
      • Doctrine Query Language peut exprimer des relations entre les données potentiellement plus compliquées que cela n'est possible avec la stratégie ActiveRecord de Propel.
      • Plus facile d'ajouter des comportements réutilisables par rapport à Propel.
      • Les commentaires basés sur DocBlock pour la construction du schéma sont intégrés dans le PHP réel au lieu d'un fichier XML séparé.
      • Utilise des espaces de noms PHP 5.3 partout
    • Les inconvénients
      • Nécessite l'apprentissage d'un tout nouveau langage de programmation (Doctrine Query Language)
      • Implémenté en termes de "méthodes magiques" à plusieurs endroits, rendant la saisie semi-automatique IDE sans valeur.
      • Nécessite une introspection de la base de données et est donc légèrement plus lent que Propel par défaut; la mise en cache peut supprimer cela, mais la mise en cache ajoute une complexité considérable.
      • Moins de comportements sont inclus dans la base de code principale. Plusieurs fonctionnalités proposées par Propel (telles que l'ensemble imbriqué) ne sont disponibles que via des extensions.
      • Freakin 'HUGE :)

J'ai glané cela seulement en lisant la documentation disponible pour les deux outils - je n'ai encore rien construit.

J'aimerais toutefois entendre ceux qui ont utilisé les deux outils pour partager leur expérience sur les avantages / inconvénients de chaque bibliothèque et quelle est leur recommandation à ce stade :)

Billy ONeal
la source
De quelle version de Doctrine parlez-vous? v2 et v1.2 sont séparés par des pôles.
Orbling
1
@Orbling: Avez-vous lu le titre ou le corps de la question? Lisez-les à nouveau :)
Billy ONeal
@Billy ONeal: Bon point. Doctrine2 a des comportements supprimés à peu près entièrement du Core, donc je pensais que vous parliez plutôt de la v1.2 à la place.
Orbling
@Orbling: Ah, c'est logique. D'un autre côté, il fournit des équivalents aux «comportements» - il ne les appelle tout simplement pas ainsi.
Billy ONeal
@Billy ONeal: Ce n'est pas vraiment le cas, vous pouvez les implémenter vous-même d'une manière assez simple, ou vous pouvez obtenir des plugins tiers. Mais ce n'est pas comme Doctrine1 ou Propel.
Orbling

Réponses:

15

Malgré la tendance actuelle à recommander Doctrine, je dois dire le contraire. Gardez à l'esprit que mes préférences personnelles sont également orientées vers mes expériences personnelles, mais comment @Dan a dit, elles sont toutes les deux très puissantes.

Je n'aime pas Doctrine pour plusieurs des raisons que vous avez mentionnées auparavant, comme la taille et l'ensemble des méthodes de magie sont les ruptures avec moi. Donc, j'utilise Propel , pourquoi? principalement parce que c'est la simplicité, et parce que simple dans le développement de logiciels est bon . Ma conviction personnelle est que devenir gourmand avec des designs est mauvais.

En utilisant Propel, j'ai réussi à implémenter une implémentation de modèle de référentiel pour mes propres systèmes, et cela fonctionne très bien, sans parler des performances de Propel, qui est l'un des ORM les plus rapides que j'ai vus.

Donc, ma réponse de base est Propel , car il accomplit un bon logiciel avec moins de code et permet à l'EDI de vous fournir une bonne intelligence sans perdre l'intérêt du logiciel ORM qui se connecte à la base de données et le fait bien ...

J'espère pouvoir vous aider

David Conde
la source
J'utilisais Doctrine depuis un an. J'ai essayé Kohana, Laravel Eloquent, j'aime leurs domaines publics parce que je déteste vraiment les getters et setters (je préfère les accesseurs immobiliers: P). Après avoir vu le mot «IDE friendly» dans Propel, j'ai décidé d'essayer Propel ce soir.
Zorji
11

Vos informations sur Doctrine 2 sont fausses ...

  • DQL est à peu près SQL, donc pas grand chose à apprendre.
  • Doctrine 2 n'utilise aucune «magie» (seulement ce que vous attendez d'une bibliothèque PHP à jour).
  • Doctrine 2 ne fait pas activement l'introspection de la base de données ... le mappage est stocké dans vos entités / fichiers de mappage et il suppose que votre base de données s'adaptera à cela.
  • La mise en cache n'est guère une «complexité considérable».
  • Doctrine 2 n'a pas de «comportements» prêts à l'emploi

Je n'ai jamais utilisé Propel auparavant, mais Doctrine 2 est beaucoup plus récente et a une base de code de très haute qualité. Mais il semble que Propel utilise Active Record, Doctrine 2 utilise le modèle Data Mapper.

L'inconvénient de Doctrine 2 étant plus récente est le manque d'exemples de tiers, mais elle s'accumule rapidement.

Je recommande Doctrine 2 ...

Cobby
la source
Si vous n'avez jamais utilisé Propel auparavant, je n'ai pas d'autre choix que de réduire ce nombre en raison du fait qu'il est FUD. Quant au commentaire "Magic", je veux dire qu'il est basé sur des méthodes magiques PHP telles que __getet __set(ce qui est vrai) plutôt que sur de vraies méthodes.
Billy ONeal
1
Ok pour le vote négatif ... Mais où Doctrine 2 utilise-t-elle des méthodes magiques? Mis à part les méthodes find * de DocumentRepository (__call), mais ce n'est pas un problème car c'est juste une meilleure façon d'interroger ... vous perdrez toujours l'auto-complétion IDE. Si vous voulez qu'ActiveRecord utilise Propel. Si vous voulez Data Mapper, utilisez Doctrine 2.
Cobby
2
Propel n'introspecte pas la base de données lors de l'exécution grâce à la génération de code.
William Durand
L'élément n ° 1 n'est pas entièrement correct, DQL n'est pas "à peu près" comme SQL. DQL dépend du fait que vous faites référence à des objets de modèle dont Doctrine doit être conscient, et il y a quelques complications si des jointures plus complexes sont nécessaires.
Mike Purcell
2
DQL est un dialecte de SQL, comment cela ne le rend-il pas "à peu près" comme SQL? Oui, la sémantique du langage est un peu différente (objets vs tables), mais en fin de compte DQL est un langage pour interroger des données structurées - qui venaient juste d'être représentées comme des objets et non des tables - alias SQL.
Cobby
3

D'après vos commentaires, il semble que vous essayez de choisir Propel ou Doctrine pour remplacer ou répondre à votre besoin d'un ORM dans une application héritée.

Cela étant dit, je pense qu'il est important de ne pas perdre de vue que le passage à l'un ou l'autre pourrait être une grande amélioration pour votre application. Donc, il n'y a pas vraiment de mauvaise réponse.

Par conséquent, la solution que vous choisissez dépend en grande partie de vos préférences en fonction de vos réponses aux questions suivantes:

  1. Laquelle s'intègre le mieux à votre solution actuelle?
  2. Quelle API préférez-vous?
  3. À laquelle préféreriez-vous contribuer? (correctifs, documentation, rapports de bogues, etc ...)

Personnellement, je recommanderais Doctrine 2 en raison de sa communauté, de sa documentation et de son architecture.

Christopher Manning
la source
1
Je cherche une comparaison entre eux ici cependant. (Pourquoi est-ce que je préfère contribuer? Vous dites que Doctrine 2 a une bonne communauté, des documents et une bonne architecture - en termes d'architecture, oui, c'est DataMapper. Docs sage Je ne suis pas sûr d'être d'accord - les deux projets semblent avoir de bons docs. Je n'ai pas vu beaucoup de communauté utiliser l'un ou l'autre système. Souhaitez-vous développer ce que vous entendez par ces choses?
Billy ONeal
2
Oh vous aimez le doc Doctrine? Avez-vous lu celui de Propel? Et oui, la communauté Doctrine est sympa mais jetez un œil au référentiel ODM, beaucoup de RP ne sont même pas commentés ni fusionnés ni rejetés ... Regardez la chronologie de Propel, la communauté est vraiment active;)
William Durand
3

Je vous recommande Propel car il est bien intégré, rapide et puissant. Générer du code est préférable à charger des classes lors de l'exécution, cela facilite les étapes de débogage et vous montre ce que vous avez créé. Donc, l'étape de construction n'est pas un problème.

Doctrine2 n'a aucun comportement officiel, et le modèle de conception DataMapper est cool mais difficile à utiliser dans la vie réelle. Oh et DQL est un langage douloureux, mais aborder à apprendre ...

Si vous voulez penser avec des objets (pas de DQL / SQL / quoi que ce soit), choisissez Propel.

Doctrine2 fait partie de Symfony2 de facto mais les choses vont bouger très prochainement, regardez le dernier article de Fabien Potencier.

À la vôtre, William

William Durand
la source
, j'ai commencé avec Propel il y a 2 ans avec symfony1. puis j'ai dû passer à Doctrine2 pour symfony2. Heureux de retourner à Propel.Cheers!
Bhanu Krishnan
2

Ils sont tout les deux très bien. Il y a des cas extrêmes dans lesquels l'un peut faire quelque chose, ou faire quelque chose de mieux, que l'autre. Partout où j'ai rencontré des problèmes avec l'un ou l'autre, cela était dû plus à mon manque de connaissances qu'à quelque chose qu'ils ne pouvaient pas faire.

Cela signifie que la documentation et le support sont plus importants que la capacité intrinsèque du code. Connaissez-vous quelqu'un qui peut vous aider lorsque vous rencontrez des problèmes? Comment vous débrouillez-vous avec la documentation? Est-ce que l'un d'entre eux «semble» plus naturel pour vous?

Dan souffle
la source
2

J'ai choisi Propel 1.63 pour une grande application mysql héritée (environ 200 tables) - les facteurs ici inclus: le support IDE qui permet aux nouveaux développeurs de trouver facilement leur chemin avec l'achèvement du code; prise en charge des schémas de bases de données croisées, performances; un meilleur support natif pour les énumérations et l'utilisation de plusieurs comportements. En fait, j'ai commencé avec Doctrine, car c'était le meilleur supporté par Symfony2, mais une fois que Propel a considérablement amélioré son support avec Symfony (la prochaine plate-forme vers laquelle je migrerai finalement), j'ai changé en raison de la meilleure gestion des problèmes ci-dessus. Pas de regrets du tout Propel est un vainqueur décisif.

Michael Heward
la source