Dovrei scegliere Doctrine 2 o Propel 1.5 / 1.6 e perché? [chiuso]

Question

Dovrei scegliere Doctrine 2 o Propel 1.5 / 1.6 e perché? [chiuso]

#1 da (15 voti)
#2 da (11 voti)
#3 da (3 voti)
#4 da (3 voti)
#5 da (2 voti)
#6 da (2 voti)

29

Mi piacerebbe sentire chi ha usato Doctrine 2 (o versioni successive) e Propel 1.5 (o versioni successive). La maggior parte dei confronti tra questi due mappatori relazionali di oggetti si basano su vecchie versioni - Doctrine 1 contro Propel 1.3 / 1.4, e entrambe le ORM hanno subito significative riprogettazioni nelle loro recenti revisioni. Ad esempio, la maggior parte delle critiche di Propel sembra centrare attorno alle classi "ModelName Peer ", che sono in ogni caso deprecate in 1.5.

Ecco cosa ho accumulato finora (e ho cercato di rendere questo elenco il più equilibrato possibile ...):

Propel
- Pro
  - Estremamente IDE amichevole, perché viene generato un codice reale, invece di affidarsi ai metodi magici di PHP. Ciò significa che le funzionalità IDE come il completamento del codice sono effettivamente utili.
  - Veloce (in termini di utilizzo del database - nessuna introspezione di runtime viene eseguita sul database)
  - Pulisci la migrazione tra versioni dello schema (almeno nella versione 1.6 beta)
  - Può generare modelli PHP 5.3 (ad esempio, namespace)
  - Facile integrazione di molte cose in una singola query di database con metodi come useXxx . (Vedi il video "completamento codice" sopra)
- Contro
  - Richiede un ulteriore passaggio di build, ovvero la creazione delle classi del modello.
  - Il codice generato deve essere ricostruito ogni volta che viene modificata la versione di Propel, viene modificata un'impostazione o lo schema cambia. ~~Questo potrebbe non essere intuitivo per alcuni e i metodi personalizzati applicati al modello sono persi. (Penso?)~~ - Non è vero; i metodi personalizzati non vengono persi perché la classe generata è una classe base; Propel fornisce una classe di entità specifica per l'estensione.
  - Alcune funzioni utili (ovvero il comportamento della versione, le migrazioni dello schema) sono in stato beta.
Dottrina
- Pro
  - Più popolare
  - Doctrine Query Language è in grado di esprimere relazioni potenzialmente più complicate tra i dati rispetto a quelle facilmente possibili con la strategia ActiveRecord di Propel.
  - Più facile aggiungere comportamenti riutilizzabili rispetto a Propel.
  - I commenti basati su DocBlock per la creazione dello schema sono incorporati nel PHP effettivo anziché in un file XML separato.
  - Utilizza PHP 5.3 Namespace ovunque
- Contro
  - Richiede l'apprendimento di un linguaggio di programmazione completamente nuovo (Doctrine Query Language)
  - Implementati in termini di "metodi magici" in diversi punti, rendendo inutile il completamento automatico dell'IDE.
  - Richiede l'introspezione del database e quindi è leggermente più lento di Propel per impostazione predefinita; la memorizzazione nella cache può rimuovere questo, ma la memorizzazione nella cache aggiunge notevole complessità.
  - Sono presenti meno comportamenti nella base di codice principale. Diverse funzionalità offerte da Propel (come il set nidificato) sono disponibili solo tramite le estensioni.
  - Freakin 'ENORME:)

Questo l'ho trovato solo leggendo la documentazione disponibile per entrambi gli strumenti - non ho ancora realizzato nulla.

Mi piacerebbe sentire da coloro che hanno usato entrambi gli strumenti, per condividere la loro esperienza sui pro / contro di ciascuna libreria, e qual è la loro raccomandazione a questo punto:)

php orm doctrine

posta Billy ONeal 17.02.2011 - 02:21

fonte

6 risposte

Leggi altre domande sui tag php orm doctrine

Consentire l'iterazione di un vettore interno senza perdite nell'implementazione Esiste un buon motivo per evitare node.js per le app web non in tempo reale?

score 15 · Answer 1

Nonostante la tendenza attuale di raccomandare Doctrine, ho bisogno di dire il contrario. Tieni presente che anche le mie preferenze personali sono orientate alle mie esperienze personali, ma come hanno detto @ Dan, sono entrambi molto potenti.

Non mi piace Doctrine per molti dei motivi che hai affermato prima, come la dimensione e tutti i metodi magici che sono gli deal breakers con me. Quindi, io uso Propel , perché? principalmente perché è semplice, e perché semplice nello sviluppo del software è buono . La mia personale opinione è che essere avidi di design è brutto.

Utilizzando Propel, sono riuscito a implementare un'implementazione modello di repository per i miei sistemi e funziona davvero bene , per non parlare delle prestazioni di Propel, che è uno degli ORM più veloci che abbia mai visto.

Quindi, la mia risposta di base è Propel , perché realizza un buon software con meno codice e potenzia il IDE per fornirti una buona intelligenza senza perdere il senso del software ORM che si collega al database e facendolo bello ...

Spero di poterti aiutare

score 11 · Answer 2

Le tue informazioni su Doctrine 2 sono errate ...

DQL è praticamente SQL, quindi non c'è molto da imparare.
Doctrine 2 non usa alcuna "magia" (solo ciò che ci si aspetterebbe da una qualsiasi libreria PHP aggiornata).
Doctrine 2 non esegue attivamente l'introspezione del database ... il mapping viene archiviato nelle entità / file di mapping e presuppone che il tuo database si adatti a questo.
Il caching è difficilmente una "notevole complessità".
Doctrine 2 non ha "comportamenti" preconfigurati

Non ho usato Propel prima, ma Doctrine 2 è molto più recente e ha un codebase di alta qualità. Ma sembra che Propel usi Active Record, Doctrine 2 utilizza il pattern Data Mapper.

Il lato negativo di Doctrine 2 è la mancanza di esempi di terze parti, ma si sta rapidamente accumulando.

Raccomando Doctrine 2 ...

score 3 · Answer 3

Dai tuoi commenti, sembra che tu stia cercando di scegliere Propel o Doctrine per sostituire o soddisfare la tua esigenza di un ORM in un'applicazione legacy.

Detto questo, penso che sia importante non perdere di vista il fatto che passare a uno dei due potrebbe essere un grande miglioramento per la tua applicazione. Quindi, non c'è una risposta sbagliata.

Pertanto, la soluzione scelta dipende in gran parte dalle tue preferenze in base alle risposte alle seguenti domande:

Quale si integra meglio nella tua attuale soluzione?
Quale API preferisci?
A quale preferisci contribuire? (patch, documentazione, segnalazioni di bug, ecc ...)

Personalmente, consiglierei Doctrine 2 a causa della sua comunità, documentazione e architettura.

score 3 · Answer 4

Ti consiglio Propel perché è ben integrato, veloce e potente. Generare codice è meglio che caricare le classi in fase di runtime, facilita i passi di debug e mostra ciò che hai creato. Quindi la fase di creazione non è un problema.

Doctrine2 non ha comportamenti ufficiali e il pattern di progettazione DataMapper è bello ma difficile da usare nella vita reale. Oh e DQL è un linguaggio sofferente ma allo stesso tempo da imparare ...

Se vuoi pensare con gli oggetti (senza DQL / SQL / qualunque cosa), scegli Propel.

Doctrine2 fa di fatto parte di Symfony2 ma le cose si muoveranno molto presto, guarda l'ultimo articolo di Fabien Potencier.

Saluti, William

score 2 · Answer 5

Sono entrambi molto bravi. Ci sono alcuni casi limite in cui si può fare qualcosa o fare qualcosa di meglio dell'altro. Ovunque ho avuto problemi con entrambi, era dovuto più alla mia mancanza di conoscenza che a qualcosa che non potevano fare.

Ciò significa che la documentazione e il supporto sono più importanti della capacità intrinseca del codice. Conosci qualcuno che ti può aiutare quando ti imbatti in problemi? Quanto bene vai avanti con la documentazione? Uno di loro si sente semplicemente più naturale per te?

score 2 · Answer 6

Ho scelto Propel 1.63 per una grande applicazione legacy mysql (200 tavoli circa) - i fattori qui inclusi: supporto IDE che consente ai nuovi sviluppatori di trovare facilmente la strada con il completamento del codice; supporto per schemi di database incrociati, prestazioni; migliore supporto nativo per enumerazione e l'uso di diversi comportamenti. In realtà ho iniziato con Doctrine poiché questo era il migliore supportato da Symfony2 ma una volta che Propel ha migliorato notevolmente il loro supporto con Symfony (la prossima piattaforma alla quale migrerò alla fine), sono passato a causa della migliore gestione dei problemi precedenti. Nessun rimpianto, Propel è un vincitore decisivo.