ORM PHP: Dottrina vs. Propel


126

Sto iniziando un nuovo progetto con symfony che è facilmente integrato con Doctrine e Propel , ma ovviamente ho bisogno di fare una scelta ... Mi chiedevo se le persone più esperte là fuori hanno pro e / o contro generali per andare con uno di questi due?

Molte grazie.

EDIT: Grazie per tutte le risposte, cose utili. Non esiste una risposta veramente corretta a questa domanda, quindi segnerò come approvato quello che ha ottenuto il voto più popolare.


5
Ragazzi, ci sono risposte aggiornate? Vedendolo così fuori moda
Qiniso il

Risposte:


76

Andrei con Doctrine. Mi sembra che sia un progetto molto più attivo ed essendo l'ORM predefinito per symfony è meglio supportato (anche se ufficialmente gli ORM sono considerati uguali).

Inoltre mi piace il modo in cui lavori con le query (DQL anziché 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();
?>

(L'implementazione di Doctrine è molto più intuitiva per me).

Inoltre, preferisco davvero il modo in cui gestisci le relazioni in Dottrina.

Penso che questa pagina dalla documentazione di Doctrine meriti di essere letta: http://www.doctrine-project.org/documentation/manual/1_2/en/introduction:doctrine-explained

Per riassumere: se avessi avviato un nuovo progetto o avessi dovuto scegliere tra l'apprendimento di Dottrina e Propel, andrei per Dottrina ogni giorno.


42
In Propel 1.5, questa query può anche essere scritta come Example_Query :: create () -> joinWith ('FooBar') -> filterId (20) -> find () (o findPK (20) dopo joinWith se Id è il tuo principale chiave). Come puoi vedere, prende la bella sintassi di Doctrine e aggiunge un po 'di più. Il rilascio è previsto per la fine del primo trimestre del 2010, ma ora puoi provarlo nei tuoi progetti Symfony.
Jan Fabry,

Bel contributo, non lo sapevo :-)
phidah,

9
l'implementazione della dottrina mi sembra molto più complessa. Get Entity gestisce get repository ... questo e quello
SoWhat

1
la dottrina è finita per complicare le cose ... solo la notorm è la strada da percorrere
Geomorillo,

40

Sono di parte, dal momento che aiuto un po 'nella prossima versione di Propel, ma devi considerare che Propel è stato davvero il primo ORM disponibile, quindi è rimasto un po' indietro quando Doctrine è stato creato, ma ora ha di nuovo uno sviluppo attivo. Symfony 1.3 / 1.4 viene fornito con Propel 1.4, dove la maggior parte dei confronti si ferma a Propel 1.3. Inoltre, la prossima versione di Propel (1.5) conterrà molti miglioramenti, specialmente nella creazione di Criteri (con conseguente riduzione della scrittura del codice).

Mi piace Propel perché sembra essere meno complesso di Doctrine: la maggior parte del codice è nelle poche classi generate, mentre Doctrine ha suddiviso la funzionalità in molte classi. Mi piace avere una buona conoscenza delle librerie che sto usando (non troppo "magia"), ma ovviamente ho più esperienza con Propel, quindi forse Doctrine non è così complicato dietro le quinte. Alcuni dicono che Propel è più veloce, ma dovresti verificarlo da solo e considerare se questo supera le altre differenze.

Forse dovresti anche considerare la disponibilità dei plugin di Symfony per i diversi framework. Credo che Propel abbia un vantaggio qui, ma non so quanti plug-in elencati siano ancora aggiornati con l'ultima versione di Symfony.


4
I nuovi miglioramenti delle query in Propel 1.5 sono davvero belli.
Tom,

23

Dipende dalle preferenze personali. Uso Propel perché (tra le altre cose) mi piace il fatto che ogni cosa abbia il suo metodo getter & setter concreto. In Dottrina, questo non è il caso.

Propel:

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

Dottrina:

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

Il motivo per cui mi piace avere getter e setter è che posso mettere ogni tipo di logica, se necessario. Ma questa è solo la mia preferenza personale.

Vorrei anche aggiungere che sebbene Propel si muovesse lentamente in passato, ora è di nuovo in fase di sviluppo attivo. Ha rilasciato diverse nuove versioni negli ultimi mesi. La versione più recente di Propel include una "interfaccia di query fluente" simile a quella di Doctrine , quindi non è più necessario utilizzare i criteri se non si desidera.


7
in Doctrine puoi sovrascrivere setter e getter per ogni proprietà e avere anche una logica personalizzata (vedi doctrine-project.org/documentation/manual/1_2/en/… - cerca ATTR_AUTO_ACCESSOR_OVERRIDE per accedere alla sezione pertinente)
Marek Karbarz

Sembra ok, ma imposti comunque la proprietà chiamando: $ x-> propname = 'abc'; Ciò è problematico perché non sembra supportare il passaggio di più parametri.
lo_fye,

20

Va notato Doctrine 2 è attualmente in fase di sviluppo rilasciato [ndr] e funzioni quasi completamente diverso da quello attuale versione stabile di Dottrina 1. Essa si basa sul modello di dati Mapper invece di attivo Record, e utilizza un 'entità manager' a maniglia persistenza logica. Una volta rilasciato, avrà una somiglianza più stretta con l'ibernazione di Java (Doctrine 1 è più simile all'ActiveRecord di Rails).

Sto sviluppando con la versione alfa di Doctrine 2 e devo dire che è una spanna sopra Doctrine 1 (solo la mia opinione e non ho mai usato Propel). È probabile che la comunità di Dottrina si sposterà verso di essa quando verrà rilasciata.

Ti incoraggio a dare un'occhiata a Doctrine, ma se preferisci lo stile di Record attivo che Propel e Doctrine usano ora, potresti voler semplicemente utilizzare Propel.


4
Una versione stabile di Doctrine 2 è stata recentemente rilasciata. doctrine-project.org/blog/doctrine2-released
Trevor Allred

5

I due riferimenti sono in qualche modo obsoleti, quindi copri comunque alcune generalità, in pratica dovresti valutare la tua esperienza con il framework in quanto tale, uno svantaggio principale della dottrina è l'incapacità di avere un IDE che ti permetta di auto-codificare in quel propell un vincitore, le curve di apprendimento propel e dottrine sono molto diverse, è più facile spingere, se il tuo progetto dovrà gestire un modello di dati complesso utilizza dottrine, se vuoi lavorare rapidamente con un ORM che è meglio documentato e trovare più supporto in Propel Internet utilizza, è molto più maturo e credo che quello più utilizzato.

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


Nel mondo di symfony sembra che Doctrine sia sicuramente la più usata, specialmente per i progetti più recenti. Naturalmente ci sono molti progetti sf 1.0 che usano ancora Propel perché Doctrine non era disponibile per symfony fino alla 1.1.
phidah,

5

Suggerirei di usare Propel 1.6 che è meglio per la funzione di completamento automatico di IDE.


26
-1 Il completamento automatico di un IDE non dovrebbe essere il motivo di una scelta tecnica
Clement Herreman,

14
@ClementHerreman Concordo sul fatto che non dovrebbero essere i criteri, ma credo che si possa essere produttivi con una particolare tecnologia dovrebbe essere una ragione per sceglierla. E con tutto il dovuto rispetto, quindi, non sono d'accordo con il tuo voto negativo ... indipendentemente dal fatto che tu sia d'accordo con la risposta, non è "sbagliato" (o è?), Ed è di qualche utilità (a meno che non sia sbagliato, nel qual caso , dovresti dichiararlo).
Sepster,

2
IMO se la tua produttività è più migliorata dal completamento automatico anziché dalla qualità del software, dall'intuitività e dalla coerenza, allora sta accadendo qualcosa di strano. Vedi codinghorror.com/blog/2009/01/… . Ma hai ragione, ad un certo punto questa risposta non è sbagliata , semplicemente non abbastanza buona, forse nemmeno buona.
Clemente Herreman,

1
@ClementHerreman, se non è utile non usarlo più;), +1
e

Ci sono risposte aggiornate a questo? Questo è fuori moda.
Qiniso,

2

Non sono un utente di ORP non framework PHP 5, ma ecco alcuni buoni post di confronto (nel caso in cui non li abbiate ancora visti):

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

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

Entrambi preferiti da Conlusion a Doctrine come una nuova generazione di ORM per Symfony.


1
Per la cronaca, questo confronto è del tutto obsoleto: l'attuale versione di Propel utilizza PDO, utilizza il supporto di relazioni molti-a-molti e ha un'ottima documentazione. Vale anche la pena considerare: alcuni di noi preferiscono lo stile di query dettagliato per la creazione di criteri rispetto ai linguaggi di query proprietari come DQL: ha il supporto IDE ed è una classe, quindi è possibile estenderlo. Sto ancora cercando di scegliere, ma vedo molti vantaggi per Propel su Doctrine, se non ti dispiace generare codice statico e puoi vedere i vantaggi del codice PHP "reale" rispetto al linguaggio di query proprietario , che è solo stringhe di un IDE.
mindplay.dk

2

Dopo averli usati per un certo numero di anni, preferisco Propel 2 a Doctrine semplicemente basandomi sul modo in cui costruisci la tua logica di query. La dottrina è la più approfondita possibile e la gestione di molti aspetti di essa corrisponde a quel livello di profondità. Propel Penso che abbia un modo più fluido e orientato agli oggetti di costruire e gestire le interazioni delle query.

Per me ciò ha comportato una riduzione del codice nel modello e più strutture attorno al modo in cui la logica può / sarà elaborata. Ciò ha comportato la creazione di molte interazioni come funzionalità comune. (Dopo tutto il 90% di ciò che farai con un database sarà solo un certo grado di operazione crudista.)

Alla fine, entrambi sono potenti, gestibili e faranno il loro lavoro. I miei progetti e interessi personali utilizzano Propel ORM 2 e progetti futuri, se ancora scritti in PHP seguiranno questa strada.

Ho usato entrambi su base giornaliera negli ultimi 3-4 anni.


1

Suggerirei di utilizzare DbFinder Plugin . Questo è in realtà un plug-in molto potente che supporta entrambi, ed è piuttosto potente. In realtà mi piace usarlo meglio di entrambi.


@Mike: grazie, non sapevo del plugin ma sembra che supporti solo fino a Sf1.2. Alla fine ho optato per Doctrine, mi sento come se fosse la scelta giusta, anche se scrivere SQL diretto è necessario per le cose più complesse.
Tom,

-2

Se non sbaglio, entrambi gli ORM utilizzano uno schema basato su XML e la creazione di queste definizioni dello schema è piuttosto complicata. Se hai bisogno di uno schema semplice basato su PHP con stile fluente. Puoi provare LazyRecord https://github.com/c9s/LazyRecord supporta la generazione automatica di script di aggiornamento e upgrade / downgrade. E tutti i file di classe vengono generati staticamente senza costi di runtime.

Utilizzando il nostro sito, riconosci di aver letto e compreso le nostre Informativa sui cookie e Informativa sulla privacy.
Licensed under cc by-sa 3.0 with attribution required.